Goose66

I believe you are saying your computer (SNAPWERXEDIT) is 192.168.1.4 (as seen in the ipconfig output) and the ISY is supposed to be at 192.168.1.161. So your setup should work fine EXCEPT your ping was routed to 192.168.1.4 so your local interface is a level above that. Make sure you don't have any VPN connection active (and kill off any VPN software). What about SNAPWERXLAPTOP? Is that a different computer?

What is snapwerx? Try an ipconfig /all and post the results.

Can you ping it?

A NAT router can use any subnet. The private subnets available include all the subnets 192.168.X.X which is 256 class C subnets (subnet mask 255.255.255.0), and 10.X.X.X which is a single class A subnet (subnet mask 255.0.0.0).

I think there is also the question of program model consistency. If all the elements of a scene were in the prescribed state (which the ISY could certainly track), does that mean the scene is "On" according to the programming model. In my mind, the answer is no. The scene is On when the scene is switched On, and the scene is Off when the scene is switched Off. An interim status of the Scene just doesn't really make any sense. But approximating the status of the scene, i.e. having a program that has an if statement that checks the state of each of the devices as paulbates suggest, makes the most sense here to me, from a programming model standpoint. Putting an actual state or trigger even in when the devices come in line with the scene configuration may be convenient, but it breaks the programming model, IMO.

I'm sorry you feel that way. Luckily your opinion of my contribution means exactly zilch.

@Michel Kohanim How about the price of the Zwave module ever being $29 again and what does stock look like on these?

Looks like this used to cost $29. Will it ever be on sale again?

I don't know how much DIY you want here, but you could look into getting a Raspberry Pi ZeroW, and then monitoring, through the GPIO pins, the status, pressure, flow rate, etc. that you want to bring into the ISY, and then implementing a remote Polyglot node server on the RPi ZeroW that communicates with Polyglot running on another, network connected RPi. There is already a Polyglot nodeserver for the GPIO on the RPi that could be migrated to a remote nodeserver, and you could customize your nodeserver to report well and pump status.

I have said this in lots of other such threads, but I will say it again here. I believe that 5.0.12 is "alpha" because Michel and Chris still don't view it as "feature complete" of the first 5.0 build, not because it is not stable. I have had no issues on 5.0.9 on (other than some minor program issues after upgrade and one crash that was caused by testing a brand new nodeserver) However, the 2844-222 is still basically not functional in 5.0.12 because you can't configure it (without a Insteon hub).

That's not how the implicit targeting feature of the Alexa groups works. It doesn't use the name of the devices in the groups to determine which ones to target with a spoken like "Alexa, turn on the lights," it uses the device type. Devices with a type of "Light" are what are turned on and off by this implicit targeting. It also appears to work with door locks. But not with thermostats, fans, or anything custom, like "bath," as of yet. All-in-all a very weak first step towards room awareness.

My setup is also all scenes exposed to Alexa as lights in the group. I had one device in the group that was a device, and it was when I disabled it in the ISY that Alexa started giving me the "Try again specifying a percentage for brightness..." nonsense. Once I removed the disabled device from the group, the "lights on" and "lights off" started working again properly.

Ok, so mine turned out to be my fault. I had put the Christmas tree in our bedroom in the group. We only took that tree down a few weeks ago, and this week I disabled the module because it was causing errors in the ISY. Evidently, having the disabled module in the group was causing the strange return of Alexa. Once the disabled module was removed from the group, it went back to functioning normally. Don't know if this is a problem in the ISY Skill that needs to be logged or not, or whether it is a problem in Alexa's logic.

Are there more details on what was involved in the ISY Portal change to support routines? Is the message "Please try again using percents for brightness or degrees for temperature" something that comes from the ISY Skill? I have literally never heard that message before from Alexa in any context until two nights ago.

My point is that "Alexa, turn off the lights" was working, now it is not. What changed?

I having some new problems with Alexa as well. For a long time now I have been able to say "Alexa, turn on the lights" when I walked into my bedroom and "Alexa, turn the lights off" when I was ready to go to sleep, and it worked swimmingly. Starting around Wednesday or Thursday this week, when I say "Alexa, turn (on|off) the lights," she says "Please try again using percent for brightness or degrees for temperature." I can still turn on and off individual lights by name, but the group functionality has changed. Was there a code change to the ISY skill uploaded recently, or is this an issue on Amazon's side?

When I sold my house last year, I removed most of the Insteon switches, but left the Icon switches in the basement because it was convenient for the kids to be able to turn off the entire basement at the KPL at the top of the stairs, and I knew the buyer had kids too. I replaced the KPL with the oldest one in my house, factory reset all of the switches, and setup all the Insteon links again without the ISY in the mix. I also had wall sconces and wall lamps in a few bedrooms that had been added after the original house wiring using InlineLincs. I removed the InlineLincs and wired the sconces into the swtiched outlet circuit in the bedroom so the lights would turn on and off with the switch. Not the fine grain control of being able to turn on just the one on your side of the bed with a mini remote or bedside KPL, but fully functional without someone saying "What happened to the wall sconces on this wall that was in your listing photos?!?"

The only thing I have seen voice profiles actually work for is music and messaging. Coming at it from the other direction, I don't see anything in the Alexa mobile app, website, or Smart Home Skill developers documentation that suggests that discovered devices, scenes, groups, or routines can be tied to a user profile on a device containing multiple user profiles. There seems to be a primary account required for each Echo or Alexa device, and that is the one that works with the Smart Home Skill aspects of the device. However, you could use different accounts for each Echo device to accomplish what you are asking for, but you would also need multiple ISY portal accounts as well. There's also the "implicit targeting" feature where you can put lighting devices and an Echo in a group, and then if you say "Alexa, turn off the lights" it will turn off all light devices in the group. You could have a group per room.

Just removing and reinserting the SD card may be enough. Note that while my ISY994i has a slot to remove the SD card, I still have to remove the circuit board from the case to actually accomplish this due to alignment issues.

As a rule, I think of events, in that the programming model is event programming. However, the exception to this is I think of things first in the divisions I have created for my devices: Outdoor, Mainfloor, Backyard, Master BR, Basement, etc. I tend to group programs in these categories as well (at least logically, if not physically). So I have a set of programs that control outdoor lighting (minus the "backyard"): one that runs at sunset, one that runs at bedtime, one that runs in the morning, etc. But I may have another group of programs for my Master BR that run at bedtime and/or morning - I don't try to combine those with the outdoor lighting programs that run on the same event.

Understanding that this approach would be temporary and that many devices would remain under the 1.1.0.0 "Undefined", I went through Mobilinc, the Alexa Smart Home Skill API (display categories and capabilities), the list of nodeservers for Polyglot, and the nodedefs.xml from Nodelink, and jotted down a quick list of Node Types that I though would be useful to Benoit and the Mobilinc/Agave guys: 2.1 – Climate Control 2.1.1 – Thermostat 2.1.2 – Temperature Sensor 2.1.3 – Climate Sensor 2.1.4 – Fan 2.2 – Lighting 2.2.0 – Generic Lighting 2.2.1 – Dimmable Light 2.2.2 – Color Changing Light 2.3 – Appliance 2.3.0 – Generic Appliance 2.3.1 – Cooking Appliance 2.3.2 – Scheduled Appliance (Roomba?) 2.4 – Barrier 2.4.1 – Garage Door 2.4.2 – Gate 2.5 – Security Alarm 2.5.1 – Security Alarm Panel 2.5.2 – Partition 2.5.3 – Zone 2.5.4 – Smoke/Fire/CO Alarm 2.5.5 – Camera (?) 2.6 – Irrigation 2.6.1 – Irrigation Controller 2.6.2 – Irrigation Zone 2.7 – Door Lock 2.8 – Media Playback Device 2.9 – Group/Scene Controller 2.10 – Power Monitor 2.11 – Occupancy 2.11.1 – Motion Sensor 2.11.2 - Geofence The list has little bearing on the ISY firmware or Admin Console, AFAIK, since they basically handle the display of all nodes in a consistent manner through their drivers (properties) and NLS entries. But it may be helpful in the Portal and for UI developers looking to make foray into 5.0 and nodeserver-supported devices, and hopefully won't be so different from the final solution that it will be hard to adjust.

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.