residualimages

even Z-wave?

@Michel Kohanim - I saw you <3'd Dennis's post, and I did edit to mention you in the post above. I assume this is pretty low on the list of development tasks to consider?

I was able to find this information at /rest/zwave/node/ZW004_306/def/get: Seems like ALARM is using a Status Names thing (the property id of "uom=25" corresponds to 'indexed values') / specific encoded Editor in the Admin Console? Maybe: UOM indexed = 25 Precision = 0 ?? = S lowMask = 0A7E ?? = N nls = IXA_AC In any case, feels like an opportunity for Universal Devices to handle the "formatted" aspect of the properties on these _306 nodes more in line with other nodes (the actual indexed string / name that corresponds to the raw value) - @Michel Kohanim, is this something you would be able to consider updating? Through REST download, I have found \core\f4\i1\nls\en_US.txt and the relevant location. Seems like I should be able to get IXA_AC-rawValue into a Notification somehow. # --- 0x06 - 306 - Access Control (0x00-0x3F) NDN-306-ICON = Alarm ST-306-ALARM-NAME = Access Control # ALARM uses these IXA_AC-0 = Idle IXA_AC-1 = Manual lock IXA_AC-2 = Manual unlock IXA_AC-3 = RF lock IXA_AC-4 = RF unlock IXA_AC-5 = Keypad lock IXA_AC-6 = Keypad unlock IXA_AC-7 = Manual not fully locked IXA_AC-8 = RF not fully locked IXA_AC-9 = Auto locked IXA_AC-10 = Auto lock not fully locked IXA_AC-11 = Lock jammed IXA_AC-12 = All user codes deleted IXA_AC-13 = Single user code deleted IXA_AC-14 = User code added IXA_AC-15 = User code not added (duplicate) IXA_AC-16 = Keypad temporary disabled IXA_AC-17 = Keypad busy IXA_AC-18 = New program code entered IXA_AC-19 = Manual code entry limit IXA_AC-20 = Unlock by RF with invalid user code IXA_AC-21 = Locked by RF with invalid user code IXA_AC-22 = Window/door is open IXA_AC-23 = Window/door is closed IXA_AC-24 = Window/door handle is open IXA_AC-25 = Window/door handle is closed IXA_AC-32 = Messaging User Code entered via keypad

In my ISY 5.3.0 firmware with Z-Wave at version 6.81.00, my August locks each show as two devices in Admin Console - one is the "ZW ### Door Lock" (which has read/write control over the lock status + operation), and the other is "ZW ### Access Control Alarm" (which has a read-only status of 'Access Control' [ALARM], and 'User Number' [USRNUM]). I can reliably use both in programs, as well as notification messages through substitution. For the "ZW ### Access Control Alarm", I currently have a very convoluted setup for sending the string value that shows in Admin Console, rather than the integer value that comes from ${sys.node.ZW###_XXX.ALARM}. I do not love it, however. Seems to be it should be easier to get the enumerated string value that shows in admin console, but I cannot figure out how to do so. For instance, here are my ZW004 node details as listed in the REST format: And if using Admin Console, I see a string of "Auto Locked" rather than the value of '9', as above: It is also available in Programs: But when the notification comes in from this setup: it comes in as the integer value of '9': I have not been able to come up with a different way to access the corresponding string enumeration directly (like I said, I do have it solved via some rather silly and complex setup). Does anyone know if there is something along the lines of ${sys.node.ZW###_xxx.ALARM.STR} or something that could be used in Notifications to return the corresponding string to the values below? Or some other fancy way to turn integers into strings without having a program or virtual device or Notification customization for each individual integer value? From what I have been able to determine: 1 = Manual Lock 2 = Manual Unlock 3 = RF Lock 4 = RF Unlock 5 = Keypad Lock 6 = Keypad Unlock 9 = Auto Lock 11 = Lock Jammed

<nodeInfo> <node flag="128" nodeDefId="VenstarF" nls="140V"> <address>n003_ven1</address> <name>Venstar</name> <family instance="3">10</family> <parent type="3">55843</parent> <type>1.1.0.0</type> <enabled>true</enabled> <deviceClass>0</deviceClass> <wattage>0</wattage> <dcPeriod>0</dcPeriod> <startDelay>0</startDelay> <endDelay>0</endDelay> <pnode>n003_ven1</pnode> <ELK_ID>L02</ELK_ID> </node> <properties> <property id="CLIFRS" value="0" formatted="Off" uom="80"/> <property id="CLIFS" value="0" formatted="Auto" uom="68"/> <property id="CLIHCS" value="0" formatted="Idle" uom="25"/> <property id="CLIHUM" value="54" formatted="54%" uom="51"/> <property id="CLIMD" value="3" formatted="Auto" uom="67"/> <property id="CLISMD" value="0" formatted="Manual" uom="25"/> <property id="CLISPC" value="70" formatted="70°" uom="14"/> <property id="CLISPH" value="68" formatted="68°" uom="14"/> <property id="GV1" value="0" formatted="0%" uom="51"/> <property id="GV2" value="1" formatted="1" uom="25"/> <property id="GV3" value="0" formatted="Home" uom="25"/> <property id="GV4" value="0" formatted="0" uom="25"/> <property id="GV5" value="99" formatted="99%" uom="51"/> <property id="GV6" value="0" formatted="OK" uom="25"/> <property id="GV7" value="0" formatted="False" uom="25"/> <property id="ST" value="70" formatted="70°" uom="14"/> </properties> </nodeInfo>

Is this something that is only expected to work with certain thermostats? Even if so, is it still working as expected? I went to add a Venstar thermostat to my Google Home setup today (Venstar through NodeLink / local Node Server) and do not see a 'thermostat' category to add the device as in the Portal. The screenshots on the wiki do not show the 'Google Home Category' having to be set -- I think I vaguely remember we didn't have to / couldn't even set that 'category' type before, but it's been a while since I added any Google Home devices.

Well, that's what happens when you think the forum is a mind reader. Corrected the oversight in the original post, thanks.

@lilyoyo1 - thanks for the recommendation, but from what I've read on ecobee sites and this forum, the ecobee API is cloud based, not local IP? Glas uses Windows 10 IoT as its OS so maybe it can be accessed locally but I can't find any API documentation other than voice assistant "skills".

I really appreciate the response, Paul. I started digging through the forums and saw some of your other posts but this is nicely succinct and looks to replicate or improve upon what Nest + Polyglot has (until the Aug 31 2019 Nest API kill date). Anything particularly "special" or problematic about these devices you've found in your 4+ years?

Hey Paul - would it be a bother to show a quick screenshot of one of the thermostat devices from the Admin Console to get a visual on the node types? Edit: reread and you use Nodelink, something I haven't done yet. I've been a Polyglot user which exposes the devices as real devices in the tree to the ISY. I'll go read up on Nodelink. From what I see, it also creates virtual devices and nodes? And do you have any wired / wireless sensors paired to it and / or integrated to your ISY? (glad to see you've already answered my V5 firmware question. I run it too)

Anyone have experience or recommendations with Ethernet or IP based Thermostats? EDIT for clarity: this is in pursuit of Local API control within the ISY (Native, NodeLink, Polyglot, or even Network Resource compatible hooks). UP32H-IP runs around $500 MSRP but supposedly allows remote sensors and local API. Think these are more likely based around commercial applications but if it works for residential... I'm seeing them for less than $300 on some sites. Other options?