Goose66

You can get a CanaKit bundle with free next-day shipping with Amazon Prime for $50. Comes with an RPi3, case, and a good power supply (other bundles may come with an inadequate PS, so be careful). If this kind of stuff is your primary use, I would skip NOOBS and GUI Desktop install and instead just download a Raspbian Stretch Lite image from https://www.raspberrypi.org/downloads/raspbian/, burn it to your micro-SD card, and use a SSH terminal program (like Remote Terminal from the Windows 10 App Store) to configure and install the Polyglot components. The RPi install is 35 minutes, and the Polyglot install is another 30 minutes and is pretty well documented in these forums.

Currently just the Occupancy node server. This is still a work-in-progress. However, there are several ways to run nodeservers on your local network to add support to your ISY for devices without the need for an RPi. Checkout Nodelink - I believe it can be run on a number of platforms. I believe Polyglot also supports any platform with the required dependencies, and has pre-compiled binaries for a number of OSes. An RPi is an inexpensive investment, and once setup is very reliable. You can also run Polyglot and Nodelink side-by-side on a $35 RPi to get the broadest third-party device support.

I was using CLITEMP as well, but changed it to ST to accommodate Benoit's requirements above.

So there doesn't appear to be a way to get a nodeserver node to change its type. I have tried adding the attribute nodeType to the node definition, changing the NLS, and even adding a <type> node to the XML for the node in nodedefs.xml. Is there any way the Portal could be updated so if a device is type 1.1.0.0 (appears to be the type for all nodeserver nodes) AND has the requisite ST, CLIMD, CLISPC and CLISPH drivers (properties), it could be recognized as a thermostat (or Thermostat would appear in the Alexa Category list) for purposes of adding the device to the v3 Smart Home Skill? This could be a temporary fix until some sort of nodeType attribute could be implemented in the nodeserver architecture.

On a separate note, I would really like to see the TEMP_CONTROL nodes for my pool controller show up as thermostats to Alexa, so I could say things like "Alexa, what is the pool temperature" or "Alexa, set the spa temperature to 101 degrees" or "Alexa, turn on the pool heater." The TEMP_CONTROL nodes contain thermostat-type driver values, such as CLISPH and CLITEMP, but not every thermostat driver, e.g., mode (CLIMD ?) is missing but it does have an ST driver that controls the On or Off status (Off, Enabled, Active). What kind of nodedef.xml entries, device type settings, category assignment, etc. would we be looking at from a design standpoint that would make it apparent to the portal and the Alexa v3 Smart Home Skill that these TEMP_CONTROL nodes were thermostats?

Nodes from nodeservers now add in Alexa as well. Can't test voice functionality until Tuesday, but just about all of mine are currently in scenes or programs, so it would only be for testing purposes that I add one directly.

+1 for this problem for Alexa as well. It is possible it has never worked since v3 Smart Home Skill and/or the Category selection option.

You could choose the two program option as well: One Trigger program that has the motion detector being switched on in the If statement and is enabled, and One Conditional program that has the other conditions (time range and status of overhead lights) in the If that is disabled. Same structure as using the folder as suggested above but extensively discussed here in these forums and in the Wiki. May be a more conventional approach than the folder.

If the sensor is sending multiple Ons and he just removes the Wait timer, then he is going to get a bad counter value and multiple notifications with each sump pump cycle.

The SynchroLinc threshold power usage depends on the order of calibration of the levels - high energy level first, then the threshold is 25% of the delta less than the high energy level, but low energy level first, then the threshold is 25% of the delta above the low energy level, which would be more effective for determining On vs. Off, IMO. I cannot verify that disabling a program halts its execution without testing - but that seems to go against my understanding of how programs work. Regardless, it seems that multiple Ons and Offs was/is the issue, so you can break your program into two programs: a Trigger Program: Sump On (enabled) If 'Sump' is switched On Then Run 'Sump Notify' (Then Path) Else - No Actions - (To add one, press 'Action') and a conditional program that is disabled: Sump Notify (disabled) If Status 'Sump' is On (Not evaluated or necessary) Then Disable Program 'Sump On' Send Notification to 'Russ' content 'Sump On' $DailySumpCycles += 1 Wait 1 minute Enable Program 'Sump On' Else - No Actions - (To add one, press 'Action')

Depending on how your SynchroLinc was calibrated, it may very well be sending multiple Ons and Offs while the pump runs. I would suggest calibrating the SynchroLinc with the Off state first (hopefully 0W) and then the On state. That way the trigger point will be closer to the low energy state. Also, if you change your program to "If 'Sump' is switched On," you will have fewer program invocations. After performing both of these steps, you may be able to remove the Disable/Enable and Wait from the program.

Sounds like your sensor for the sump pump running is "bouncing," i.e., sending multiple Ons and Offs during a single run. Each time the status of the "Sump" device changes, the program is run anew and any running copies, e.g., sitting in Waits, are cancelled. So that's why the variable is never incremented. Can you tell us what type of device "Sump" is? One thing to try is something like this: If Status 'Sump' is 100% Then Disable Program 'Sump ON' Send Notification to 'Russ' content 'Sump On' $DailySumpCycles += 1 Wait 1 minute Enable Program 'Sump ON' Else - No Actions - (To add one, press 'Action')to move the

I assume the wait is to only update the counter if the sump stays at 100% (On?) for more than a minute. So I suspect that this is the issue. It is hard for me to imagine a sump pump running for more than 4 or 5 seconds, much less a minute. But I don't know what your installation looks like.

If security of remote access is the issue, might I suggest a VPN into your LAN, and then simple http access to the ISY from the Admin Console. Alternatively, use RDP or Go2MyPC or equivalent to access a PC on your LAN and run the Admin Console there.

That doesn't really explain why it would be so much slower over https, though. My machine is not that fast (core i5-2500K @ 3.60 GHz) and it has no problem running the Admin Console in Java.

I had these errors in some programs after going to 5.0. Just editing and saving the programs fixed it. I think there are/were bugs in the program conversion process, and they show up as "Out of Memory" errors in the UI.

It is worth noting that if the ISY turns a Scene on or off, e.g., by way of a Program, there is no Insteon Scene Clean-up Sequence such as would occur if the Scene was triggered directly from a controller Insteon device. Therefore, it should make no difference to putting a Wait between scene commands because there is just a single command put on the Insteon network to turn the scene off with no followup cleanup commands.

Have the program turn off the scene containing the three buttons in the Else statement (that is what runs when you ask Alexa to turn off a program). As far as the If statement in the program AND the enabling of the program at the end of the Then branch, what are you trying to accomplish there?

You don’t have an “Alexa Category” pulldown in the dialog that comes up when click the Add Program tab? Sent from my iPad using Tapatalk

You can choose how the program/device/whatever is presented to the Alexa skill in the portal. Ultimately, you are going to want the network resources to be called in programs if you are going to implement a sensor to control the open/close aspect. Go ahead and create the programs in the ISY and then categorize them to the Alexa skill as "device/light" or "device/switch". Now you can put them in Alexa groups and routines.

I just put the date ranges for three or four years in an if statement. Nothing in my home automation systems stays consistent that long anyway, and if it were I would just have a very simple change to make every four years.

You can put the the KPL buttons in the scene that implements your virtual multiway circuits as controllers and responders (in other words, the KPL button is just another switch in the virtual multiway circuit). If a KPL button is actually associated with multiple, different virtual multiway circuits, then you have to create a new scene that has the KPL button and all of the switches from each of the different multiway circuits to control the on and off. You then have to have a program that syncs the status of the KPL button light with the state of the switches controlling the load(s) in each of the virtual multiway circuits, e.g., turn the KPL button On if the status of any one of the switches is on, otherwise turn the KPL button off (or vice-versa, depending on how you want it to work).

Anybody with an extensive Insteon installation ever user a power line networking solution, like TP-Link AV600? I am needing to get wired network connection to an outbuilding and hopping it over multiple wi-fi extenders is just not working well. I was going to try the TP-Link devices but I don't want it to bring down my Insteon network.

The thing about the portal subscription is that UDI has recurring costs for renting the server time (as well as ongoing maintenance and enhancement of the Alexa and Google Home skills). It sort of makes sense that the portal be a subscription, right? Sent from my iPhone using Tapatalk

I think the Open thing may be a security feature. I know that your Smarthome Skill can't allow garage or other doors to be opened on an "Open" command in order to pass certification. But the weirdness and inconsistency in the responses is what's interesting Would be interested in knowing if it’s coming from a return code from the Skill or from the Alexa side. Perhaps Brian Mercier can shed some light on that question.