Goose66

Perfect! Are you thinking it would be something we add in the nodedefs.xml and that would then drive output of the REST interface? I think the Mobilinc and Agave guys would be interested in this too.

But then you run the risk of the wait timer being cancelled by the occurrence of one of the other conditions (the times in the time range, status of the overhead light changing) and therefore your perimeter lights never being turned off. This is the classic source of confusion with the ISY programming model (not to mention why the Else branch is practically worthless) and why so many use the two program approach as a matter of course to separate their trigger events from their conditional statements.

The program status of this program will always be True, because there will never be a time when the IF statement is evaluated as false.

I think there are more nodeservers coming for the Portal - maybe even a Polyglot framework for Portal-based nodeservers. However, that really only makes sense for nodeservers that connect to cloud-based services (such as MyQ garage door openers), and I worry about what these cloud-based service providers are going to think about 100s of requests a minute coming from the same IP address. For local devices, having the nodeservers running locally on the LAN is going to offer better performance, and it also would ultimately be better for cloud-based services, IMO, because it spreads the network load out somewhat.

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.