Goose66

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.

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?