SJK

The new 5.9.1 release and the instruction/admonition to ensure you have good backups before proceeding got me thinking. Do I understand the complete backup strategy? I didn't find the complete answer here so thought I'd ask. Obviously there's the "backup IoX" menu item. Used to take a long time- now it's incredibly fast and makes a small zip file- too small... Makes me wonder what's not included. What does the backup IoX file include? All programs? All configuration tab items? Per the migration guide it seems like an all-in-one backup. But IIRC my migrations in the past were not smooth (but there were version and hardware differences- was not a straight like for like restore) requiring a fair amount of re-work. Topology file? (Good to have, not a restorable item but contains some very valuable information) PLM links table? I've found a few of those files lying around my backup folder and cannot figure out how to do that again if needed. As above- do I backup my programs separately? (Even if included in the main file)- a good idea in case a partial restore is needed due to a programming misadventure? If I export the root folder of my programs- are all included or just that root folder? File size seems really small given the amount of programs I've built. Variable definitions? Main file I'd expect? Z-wave- don't use it but see there's a separate procedure to backup a Z-wave network. What about ZigBee? Matter? Polyglot- has it's own backup system. Any caveats there? UDMobile is relatively straightforward, obviously a separate step. I have multiple production devices- no spare equivalent test devices- not interested in blowing up my controllers to f-around and find out on my own if my backup is complete at this stage. What does everyone do?

More sonoff devices- Water leak sensor is recognized as a water leak sensor class device by IoX with multiple parameters but water leak detection events are not received. https://sonoff.tech/product/gateway-and-sensors/snzb-05p/

Agree - I started with this 20 years ago now with Insteon V1 and and Elk integration using the X10 commands and some dedicated hardware interface between the two. Now 2 homes and 2 businesses later I'm on my 5th and final buildout with my preferred kit. So as I said- dipped toes into water with HomeKit (or spent the time in HA rabbit holes)- can keep it, but not any killer feature to layer on top of a polished IoX setup. It's just hard to follow with all the Matter this and Thread that hype- sounds great for interoperability in simple setups, but IoX already is integrating and translating between vendors and protocols just fine.

General question: What's the advantage of integrating HomeKit (Apple) to IoX? I'm not sure what I'm missing out on by not doing this and interested in the killer functionality this provides given all the talk re: Matter, etc. With the pending January update just announced, I'm thinking the advantage is even less. I'd understand if someone started with a HomeKit environment and fell into IoX, but not the other way around. I have an Insteon-heavy environment, so IoX is ideal there. I have branched out into Zigbee 3.0 (Hue bulbs, Sonoff switches, GLEDOPTO devices for LED strips and architectural lighting) but also use Polyglot for UniFi, Venstar, Elk, and CAO/Wireless Tags integrations. An eISY and a Polisy running IoX and Polyglot are my only hubs. The admin console programming setup is very flexible- things often require multiple small programs making sort of a web of interactions (vs a HomeAssistant script for example) but it's intuitive. Any limitations I've run into when trying to accomplish something is more often hardware-based, rather than IoX capabilities itself- with a few exceptions of trying out some cheap "unsupported" devices. Perhaps that's it? People using a mishmash of cheap consumer devices of the week that are supported in HK or HA and may not have made it into IoX yet? I'm not currently using ZWave at this house but am in commercial settings. So what's the advantage? A prettier UI from Apple instead of UDMobile? Even there, UDMobile is awesome- I've built a massive interface for my iPhone allowing me to control multiple IoX systems at multiple in one place. And I try to automate most actions so I don't need to fiddle around in the app to live my life- my home just does it's thing and responds to presence, motion, climate/weather/luminance, etc. I use Insteon keypads for most manual interaction and am installing a wall-mounted iPad to run UDMobile and a web browser for other home services (calendar/shopping list, etc). I'd rather not have to whip out my iPhone as I walk around my house to trigger events. I interact with Elk directly for security when home, which IoX monitors to trigger some routines, and UDMobile if I need to interact with or monitor the security system when away from the premises. I'm using UniFi protect for cameras (and access at commercial settings) but they have their own apps and I don't really need them to integrate with IoX. and then I could integrate an RSTP camera stream to UDMobile if desired (not sure of that other than quick access to a key feed or two in case of an alarm event rather than switching apps- maybe). Sonos and Roku aren't well integrated into IoX via Polyglot- always ran into issues with them (some self-inflicted based upon enforced network segmentation)- but then Sonos has an app if I want to interact with it, and I can use the IoX network module if I want to program a specific action such as pressing an Insteon key to turn on the radio while cooking, etc. What are people doing with HomeKit and HomeAssistant if they've got a mature IoX setup?

Sonoff ZBMINIR2 on/off switch. Currently able to be added as a Zigbee device, on/off works, but no ability to configure/mange device settings such as detached mode, inching mode, trigger mode, power reset state. My use case is to sense a local switch for Hue bulbs to toggle on/off state without powering off bulb entirely (originally wired it as a local failsafe switch/if we ever sell the house and revert to "dumb" wiring). A whole lot cheaper than another insteon switch with a disconnected load. https://www.zigbee2mqtt.io/devices/ZBMINIR2.html https://sonoff.tech/product/diy-smart-switches/zbminir2/

I currently have zero Z-wave devices at this location so could live with that. Too many scenes with each devices a member of multiple scenes to accommodate on insteon PLM. Attached article not too helpful- one network manager per network- but I'm looking at making multiple independent networks - or at least that would be fine as I see no need to make both see each other. It does mention "start network and join/leave network" so presumably each controller should set up their own independent network - otherwise how would interference between neighbors be prevented? Found this: https://www.rfwireless-world.com/Tutorials/Zigbee_tutorial.html which mentions each controller starts its own personal area network- so I can see on my eISY this in X-ray of the network: Integer DATA controller.data.defaultPanId = 27238 (0x00006a66) I would assume that if I bought another ZMatter dongle it would create a different network ID- either randomly or upon detecting a collision with an existing network but that is a something one of the UD developers would have to confirm.

As an aside- just received my first actual Philips Hue bulbs and tried one out. Amazing that I can set commands directly with scenes included alongside Insteon switches- so I can use the regular wallswitch button to turn the light on AND reset the temp back to a "normal" bulb rather than the last on. Well done native implementation! Kudos!

I don't have a large zigbee network, I have a large Insteon network. The Zigbee devices will be in locations covered by each of the IoX controllers (max nodes/scenes/devices per PLM) and cannot be reconfigured to condense the Zigbee network to one IoX controller.

I have a corner-case question here regarding Zigbee (and possibly ZWave). I have an eisy and a polisy both running in the same home as my Insteon network is too large for one to contain all nodes. The polisy handles exterior and basement, the eisy handles floors 1-3 in the main home and the entire HVAC system. Polisy handles polyglot and external intgrations and the eisy references polisy for polyglot. I'm now adding Zigbee to my home- currently for Hue-style lighting using the GLEDOPTO 5 in 1 LED drivers and their exterior wall wash and garden lighting (integrated Zigbee 3.0). Problem is I'll have some inside the home, where it will be important for them to integrate with the interior scenes and programs on eisy, and also the garden/wall wash exterior ones which should be integrated with the exterior scenes- on polisy. Since z-matter works without a hub I don't have one so I don't need or want to use polyglot/nodeservers. That would make this easier as both could "see" the nodes (like I do with Elk). I have no problem getting a second ZMatter dongle for the Polisy. But then I have two controllers. Can they be on the same network? Should I just change the frequency of one of them (no idea how to change the frequency of the listening devices or if they even support that)? I don't have any way I can reconfigure which IoX controls what given the HVAC is all on eisy and I've previously run out of Insteon nodes/scenes and my final insteon network plan has gotten substantially bigger since then. Thoughts?

On the device dashboard for a variable the top 3 pickers are under the properties header- value precision and startup value. Value is where is get that error- tried with variable dashboards of status commmand and default types. Below that under a command header is a blue button for value which will accept an arbitrary value. Since the property picker is first (and there and accepts a value) it’s what I always click on.

Sorry if this is double post, but I can't find it with search so I'll ask the question here. I have a few minor issues with the mobile app on iOS: When I go to manually input a variable value in a entity's dashboard, I cannot enter a value greater than 100. Obviously in the admin control panel I can enter any value I wish. Obviously if you were looking at status of a light entity a hard limit of 0-100% would make sense but I'm talking about a integer or state variable which should be able to hold any value. The value can clearly be something other than 0-100 because I can view variables set via my programs with arbitrary values. Similarly I cannot set the value from the variables list directly outside of an entity/device dashboard. If I create an entity/device of type command with dashboard, the ability to edit the commands at the bottom of the pane disappears. I can add new steps but cannot edit existing steps. The little right arrow/Chevron that would open up the command to edit literally isn't there. If I change the entity to type command then the Chevron appears, and I can edit a previously entered command step. A question on trying to create a button that when pressed would increment a value. Due to how I've laid out the pane in question, I don't want to use the increment button type. I'm not trying to manually adjust the value directly to an arbitrary value- It's really that I want to press the button and have it add 30 or 60 (minutes) to the existing state value being used to feed a timer program. The command entity cannot add to an existing value (+=), only assign the value directly (=). Am I approaching this wrong or is this a limitation of the app? I could write an increment program in the admin console and have that button run the then step of the program I guess but that seems like a workaround. Overall, kudos with the app. It's really grown and has become indispensable to running my home (as much as I've automated everything to require minimal interaction.)

No. It’s an API call to a REST URL with parameters. GET/POST command with the inbuilt network module will suffice. I use IOX variables to hold state variables for status and integrity variables for the desired setting prior to the call.

I have noticed that occasionally some nodeservers stop working on my eISY's IoX admin console. What I've traced it to is the nodserver profile address on the IoX service. Polyglot is working fine- the nodeservers are fine, but IoX changes the URL/IP of the nodserver to 127.0.0.1. I run both polisy and iox due to running out of Insteon nodes a while back so I split the install. The polisy is older and is already running polyglot so I kept it there. I do not use the eISY's polyglot install. Instead i've added both ISY mac addresses to the polyglot server on the Polisy and run the required nodeservers there in one or both profiles as required. That cuts down on licensing and keeps everything in one place, simplifies updating, etc. It works fine and seems analogous to when polyglot first came out and I'd run it on a RPi with an ISY/99. But if there's a network hiccup, or I update a nodeserver (so it goes offline) the eISY will often revert to a local address, breaking the connection. Oddly the nodeserver is still listed as online in its node but control breaks. (Like the Elk module will pick up events - violations, arming, etc. but I cannot send any commands from IoX). Go to the profile and put in the correct IP address and everything is fine again. This is longstanding behavior- as long as I've split out to two systems. Note I haven't figured out how to completely turn off the eISY's polyglot service. I don't see an option to do so. I could write a script to disable the service but I'm sure a future update will revert that or break a version update or something so I'd rather not go hacking around in a command line. But the eISY polyglot isn't running anything- no nodeservers, etc. Previously I'd be able to log into the eISY polyglot -not that I need it for anything thought- but I just tried while writing this post so that I could again confirm it's idle. I couldn't log in via the website/port 3000. So I logged in via the console and checked the logs: Jan 18 17:05:04 eisy daemon[2932]: 1/18/2024, 17:05:04 [pg3] ^[[32minfo^[[39m: call_udx: Making request to socket with url /rest/pg3.auth.ns Jan 18 17:05:05 eisy daemon[2932]: 1/18/2024, 17:05:05 [pg3] ^[[32minfo^[[39m: call_udx: Making request to socket with url /rest/pg3.auth.ns Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: Verifying node servers are installed on IoX correctly Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: IoX Request: [Try: 1] [00:21:b9:02:64:d7] :: - http://127.0.0.1:8080/rest/profiles/ns/0/connection Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: IoX Response: [Try: 1] [00:21:b9:02:64:d7] :: [200] :: 3.1233ms - http://127.0.0.1:8080/rest/profiles/ns/0/connection Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_1] Unmanaged NodeServer 'UnifiPresence' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_3] Unmanaged NodeServer 'WirelessTag' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_2] Unmanaged NodeServer 'ELK' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_4] Unmanaged NodeServer 'Timedata' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_5] Unmanaged NodeServer 'Holidays' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_6] Unmanaged NodeServer 'Sun' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_7] Unmanaged NodeServer 'OpenWeatherMap' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_8] Unmanaged NodeServer 'Virtual' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_9] Unmanaged NodeServer 'Roku' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_10] Unmanaged NodeServer 'Plex-WebHook' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_11] Unmanaged NodeServer 'VenstarCT' found. Adding to DB. Jan 18 17:05:06 eisy daemon[2932]: 1/18/2024, 17:05:06 [pg3] ^[[32minfo^[[39m: [00:21:b9:02:64:d7_12] Unmanaged NodeServer 'NOAA' found. Adding to DB. Jan 18 17:05:08 eisy daemon[2932]: 1/18/2024, 17:05:08 [pg3] ^[[31merror^[[39m: UDX authentication failure for admin with cause udxTimeout: Error: udx /rest/pg3.auth.ns - ECONNABORTED: UDX timeout after 4000ms Jan 18 17:05:09 eisy daemon[2932]: 1/18/2024, 17:05:09 [pg3] ^[[31merror^[[39m: UDX authentication failure for admin with cause udxTimeout: Error: udx /rest/pg3.auth.ns - ECONNABORTED: UDX timeout after 4000ms Never seen that before- every 5 minutes it's polling IoX and adding nodes to the internal database. Never saw that before. Last night I upgraded packages on both polisy and eISY to get to IoX 5.8.1. Thoughts?

One more thought if this is relevant to your decision: Venstar API is local. I am free from and service/cloud dependency. I'm not opposed to using one, but we all know services shut down or change their business models, nodeservers get abandoned, etc. Skyport is there if I wanted some cloud-baed vendor-supported tool, but separate from the API access which is on-device. Isn't ecobee reliant on a cloud connection to their servers? I've never used them so I could be mistaken, but when I was looking at them I recall that was an option- they have a cloud service which they are pushing people into to get some "security" functions out of the sensors (motion, window monitoring, etc). That required a subscription to enable and I didn't find that appealing. Also if you do go ecobee- look at your utility provider- many have discounts for purchasing a "smart" device through them and lots partner with ecobee or nest. Pay up front, pay later, or pay with your data.

I vaguely remember a scheduled reboot feature in the old ISY. I cannot find it on IoX now. I wanted to try a scheduled weekly reboot because I'm having stability issues lately. eISY will hum a long for weeks then all of a sudden everything goes wonky- variables and program status seems off and things stop responding properly with no changes in the setup. I have a lot of programs and variables including currently 223 state variables and 295 integer variables. I'd think eISY can handle it but perhaps there's a memory leak somewhere. In any case a reboot seems to set everything straight for a while. Is the option for a scheduled reboot still possible somewhere?

Also look into notifications via UDMobile. Much more reliable and there's a wiki post to help you configure the network resource.

Elk? Old school but very capable. On my 3rd home install with them. It gets expensive quickly though. The Elk Nodeserver is top-notch.

Feel compelled to chime in as I've used multiple brands of thermostats with ISY/Iox over the past almost 2 decades across multiple homes and business properties. Insteon- never tried - was scared off with the issues posted all over these forums Honeywell native Z-wave (the ugly green screen ones supplied by some utilities as they also handle ADR/load shedding) - work fine, no nodeserver required. Still use one at one of my rental properties. Annoying to deal with as it had a weak Zwave antenna and I was on the old ISY at the time- had to do an external antenna - Still had transient issues as the rest of the place was mostly Insteon so did not have a robust Zwave network (back in the 300 series days). Radio Thermostat CT series- also had multiple of these. They worked poorly. Do not need a nodeserver. Not sure if it was a poor quality Z-wave network (in these properties had multiple other Z-wave devices and repeaters, etc- tried everything - zwave 500 setup). Gave up on them and ripped them out. Programmable, has some options, but far behind in features compared to the following. Basic-looking in a home. Honeywell T6s- similar to the T9s below as far as equipment capability but without the app control. Inherited several in a commercial property and replaced them with the T9s. I really like their install and setup process. But I needed remote control for that application. Honeywell T9s- the cute ones now on Resideo (old Honeywell Home)- wasn't able to get the nodeserver setup done and relies on someone hosting a small free Amazon ECS instance. So never integrated them into IoX. App control is nice- I still use them at 2 commercial properties with their inbuilt schedules + app overrides. Had them at my home as well with remote sensors which averaged the temp across the home (use radiators, so that was a key). They have lots of features and can handle various multistage heating/cooling equipment setups. Ripped them out of my home in favor of Venstars- Wifi-enabled. The CT series is great as is the Explorer series. Have both app control (Skyport cloud- their servers) and nodeserver support. App is nice but I rarely need it as I have the IoX. Helped with configuration though. Nodeserver for CT series works fine, but is polling all the time which makes programming difficult. Isn't able to control the Explorer series. Ventar has an API which can do HTTP/HTTPS. Therefore I use the inbuilt network module to control (send commands via API calls) and the nodserver to read status. Also use their Explorer series which is slightly cheaper but in some ways more capable in 4 of the bedrooms. Have lots of features but many I honestly don't use as I prefer to manage centrally via the IoX as I'm running dual fuel with progressive radiant takeover based upon exterior temperature. Handles remote sensors (wired and wireless) with multiple control options including averaging or various onboard/wired/wireless sensing. Really a great set of thermostats. Ripped everything out of my home in favor of these and not looking back. Anyone need some used thermostats?

Yes, I tried that as noted above (lots of detail, I know- thinking my way through it). Integer "heattemp=68&cooltemp=75" or floating point/decimal "heattemp=68.0&cooltemp=75.0" makes no difference- both are supported on both models of thermostats. Currently with the network resource approach I'm directly using an integer variable without any issue. Direct curl commands curl -X POST -d 'heattemp=71&cooltemp=78' http://10.10.60.104/control {"success": true}% curl http://10.10.60.104/query/info {"name":"OFFICE","mode":1,"state":1,"activestage":1,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":71.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":36,"availablemodes":0}% curl -X POST -d 'heattemp=70.0&cooltemp=76.0' http://10.10.60.104/control {"success": true}% curl http://10.10.60.104/query/info {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":76.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":36,"availablemodes":0}% I'm still wondering if the POST format header matters. Without specifying a content-type directly, curl sends the data using the application/x-www-form-urlencoded Content-Type. I don't know what the default type is for the REST extension I was using in VS Code but omitting the header also worked, so I'm assuming it's the same. I'm explicitly using that header in the network resources. In your nodeserver, no headers are defined. Do you know what the default format is for the library you use? Although with testing I'm not sure as I get an error response with the POST to the Explorers using multipart form data content type which I would expect to see in the nodeserver logs, but I do not. On the other hand, the ColorTouch reports success with multipart form data - but does not change the setpoints. curl -X POST -F 'heattemp=62.0' -F 'cooltemp=76.0' http://10.10.60.104/control {"error":true, "reason": "'--------------------------2ee368cbd9439dfe Content-Disposition: form-data; name' Datapoint does not exist"}% curl http://10.10.60.104/query/info {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":76.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":36,"availablemodes":0}% curl -X POST -F 'heattemp=62.0' -F 'cooltemp=76.0' http://10.10.60.103/control {"success":true}% curl http://10.10.60.103/query/info {"name":"Master Bedroom","mode":1,"state":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":255,"away":0,"spacetemp":68.0,"heattemp":69.0,"cooltemp":75.0,"cooltempmin":72.0,"cooltempmax":99.0,"heattempmin":35.0,"heattempmax":78.0,"activestage":0,"hum_active":0,"hum":47,"hum_setpoint":0,"dehum_setpoint":80,"setpointdelta":2.0,"availablemodes":0}% 10.10.60.104 is an Explorer 10.10.60.103 is ColorTouch Similarly if I explicitly set the content type to JSON I get an error on the Explorer and nothing is changed but I get a success on the ColorTouch yet settings are not changed. curl -X POST -H "Content-Type: application/json" -d '{"heattemp":63,"cooltemp":79}' http://10.10.60.104/control {"error":true, "reason":"Incorrectly formated request"}% curl http://10.10.60.104/query/info {"name":"OFFICE","mode":1,"state":1,"activestage":1,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":69.0,"heattemp":70.0,"cooltemp":76.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":36,"availablemodes":0}% curl -X POST -H "Content-Type: application/json" -d '{"heattemp":63,"cooltemp":79}' http://10.10.60.103/control {"success":true}% curl http://10.10.60.103/query/info {"name":"Master Bedroom","mode":1,"state":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":255,"away":0,"spacetemp":69.0,"heattemp":69.0,"cooltemp":75.0,"cooltempmin":72.0,"cooltempmax":99.0,"heattempmin":35.0,"heattempmax":78.0,"activestage":0,"hum_active":0,"hum":46,"hum_setpoint":0,"dehum_setpoint":80,"setpointdelta":2.0,"availablemodes":0}%

In absence of working control of Explorers I've created some network resources and 4 additional variables per Tstat to essentially mimic the nodeserver. The nodeserver is still used for polling, but multiple programs exist (previously planned) to compare desired to actual state. If there is a difference, the new integer variables are set (mode,fan,heattemp,cooltemp) and then passed to a network resource for the tstat to set the desired parameters. There's a wait in there to allow another poll prior to setting/calling to prevent a race condition among programs. I use a separate resource for each thermostat instead of passing the (fixed) IP as a URL parameter as often multiple need to be set at the same event (away setback for example) and each zone can be in different states (heating vs idle or with different setpoints) so it seemed best not to re-use the variables across the home, but that means 40 variables and 10 network resources. For consistency and simplicity amongst programs and variables and overall approach I'm going to replace the direct settings of the colortouch thermostats with the same setup as well. That actually allows for easier control as all 4 can be specified in one API call rather than setting a heat setpoint, adding in a poll wait, then setting a cool setpoint which leads to logic loops. Alternative is separate programs for each of mode, fan, heat and cool setpoints for each TSTAT and each state (sleep, occupied, vacant, away, vacation)- a lot of additional programming.

Could this have anything to do with it? (TL;DR No it doesn't) # Venstar ColorTouch Local REST API v4 spec. _API_HTTP_HEADERS = {} try: response = self._session.request( method, url, params = params, headers = _API_HTTP_HEADERS, # same every call timeout= _HTTP_POST_TIMEOUT if method == "POST" else _HTTP_GET_TIMEOUT When sending a POST request via the API the documentation states POST /control HTTP/1.1 Content-Type: application/x-www-form-urlencoded mode=0&fan=0&heattemp=70&cooltemp=75 Is the "Content-Type" header missing or am I missing something in the code (not a python developer) When I POST that via VS Code REST extension POST http://10.10.60.104/control HTTP/1.1 Content-Type: application/x-www-form-urlencoded mode=1&heattemp=69.0&cooltemp=75.0 It works. When I omit that header It still works on both CT and Explorer. Well it was a thought at least.

I'd suggest the Honeywell T10 series then. As was said in the other thread, you can use the app to view the remote temps and determine which ones are used to average out the reported temperature. While I'm not sure you can change which is used programmatically (ask about that to the Honeywell nodeserver developer) you can set which are used in the thermostat programs. So you can create a program in the thermostat with an evening/night start time and set it to ignore that sensor when heating/cooling the house as a whole. Then just leave the IOX to work based off of the thermostat's reported temperature for whatever need you have there. And if that's the main/only thermostat- spend the time/effort to move it to a central area of the home!

Schedule mode: Agreed- should be an easy fix- the API documentation lists both schedulepart and scheduledetail but doesn't detail which thermostats report what. All of the possible responses are detailed but it's not very clear on which are actually used. On the Explorers you can set the thermostat to programmable 7 day, learning, or nonprogrammable. On the ColorTouches you cannot set it to nonprogrammable, but you can disable each timeslot of the program as well as set it the program active/inactive. Temp setpoints: I initially tried just changing one parameter on the Colortouch via the API (mode) and it didn't work- wherein I discovered in the API docs that is appears to indicate you have to send both heat and cool setpoints together as one command. While odd I figure it's standardized in case auto mode is specified. That is the behavior on the currently released firmware for my ColorTouch but NOT the Explorers. I just did some more rigorous testing because I'm confusing myself here: ColorTouch (Firmware version VH6.93) Unless I send both heattemp and cooltemp setpoints together in one call I get an error that "Both Setpoints are required". So perhaps they've changed the API. I cannot tell as it's not versioned with a changelog. I can send the fan setting individually and I get success responses and the expected behavior. If I try to change the mode individually, I get an error back "Missing Setpoints when changing mode". So it appears on the ColorTouch now that fan is ok individually, mode requires both setpoints, and any setpoint change requires both setpoints. Explorer (FW 5.28) I can send any of the 4 parameters- mode, fan, heattemp or cooltemp individually via the API and I get a success:true message and the expected behavior. (???) Tested with multiple thermostats- all same FW (latest)- I have 2 ColorTouch and 5 Explorers at the moment. I can send both setpoints at the same time heattemp=68&cooltemp=75 and I also get a success message and the thermostat responds. I can send a mode setting along with both setpoints and I also get a success message and the thermostat responds appropriately. However: I can send increase/decrease setpoint commands to the ColorTouches via the IOX buttons. The UI changes instantly, then after a short lag the thermostat responds. Same with schedule mode. With the Explorers, I cannot. The UI changes then flips back at the next shortpoll. Here's the nodeserver log when I send an "increase setpoint" command by pressing the button in IOX for an Explorer thermostat: 2023-11-06 12:44:22,862 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message command 2023-11-06 12:44:22,862 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message command 2023-11-06 12:44:22,864 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING command 2023-11-06 12:44:22,865 Command udi_interface INFO nodes:cmd_inc_dec: Increase or decrease temperature of OFFICE in command handler: {'address': 'xa0a3c68', 'cmd': 'BRT', 'query': {}}. 2023-11-06 12:44:22,866 Command udi_interface DEBUG venstarapi:getThermostatState: in API getThermostatState()... 2023-11-06 12:44:22,864 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING command 2023-11-06 12:44:22,865 Command udi_interface INFO nodes:cmd_inc_dec: Increase or decrease temperature of OFFICE in command handler: {'address': 'xa0a3c68', 'cmd': 'BRT', 'query': {}}. 2023-11-06 12:44:22,866 Command udi_interface DEBUG venstarapi:getThermostatState: in API getThermostatState()... 2023-11-06 12:44:22,867 Command udi_interface DEBUG venstarapi:_call_api: HTTP GET http://10.10.60.104/query/info data: None 2023-11-06 12:44:22,867 Command udi_interface DEBUG venstarapi:_call_api: HTTP GET http://10.10.60.104/query/info data: None 2023-11-06 12:44:22,971 Command udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0} 2023-11-06 12:44:22,971 Command udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0} 2023-11-06 12:44:22,973 Command udi_interface DEBUG venstarapi:setThermostatControls: in API setThermostatControls()... 2023-11-06 12:44:22,973 Command udi_interface DEBUG venstarapi:setThermostatControls: in API setThermostatControls()... 2023-11-06 12:44:22,974 Command udi_interface DEBUG venstarapi:_call_api: HTTP POST http://10.10.60.104/control data: {'heattemp': 71.0, 'cooltemp': 78.0} 2023-11-06 12:44:22,974 Command udi_interface DEBUG venstarapi:_call_api: HTTP POST http://10.10.60.104/control data: {'heattemp': 71.0, 'cooltemp': 78.0} 2023-11-06 12:44:23,828 Command udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"success": true} 2023-11-06 12:44:23,828 Command udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"success": true} 2023-11-06 12:44:23,830 Command udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE Reporting set CLISPH to 71.0 to Polyglot 2023-11-06 12:44:23,830 Command udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE Reporting set CLISPH to 71.0 to Polyglot 2023-11-06 12:44:23,831 Command udi_interface.node DEBUG node:reportDriver: Updating value to 71.0 2023-11-06 12:44:23,832 Command udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLISPC's value 2023-11-06 12:44:23,831 Command udi_interface.node DEBUG node:reportDriver: Updating value to 71.0 2023-11-06 12:44:23,832 Command udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLISPC's value 2023-11-06 12:44:23,850 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'xa0a3c68', 'driver': 'CLISPH', 'value': '71.0', 'uom': 17, 'text': None}]} 2023-11-06 12:44:23,850 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'xa0a3c68', 'driver': 'CLISPH', 'value': '71.0', 'uom': 17, 'text': None}]} 2023-11-06 12:44:23,966 MQTT udi_interface.interface INFO interface:_message: Successfully set xa0a3c68 :: CLISPH to 71.0 UOM 17 2023-11-06 12:44:23,966 MQTT udi_interface.interface INFO interface:_message: Successfully set xa0a3c68 :: CLISPH to 71.0 UOM 17 Odd- reports success. But the value did not change in the UI, nor the TSTAT. And the next poll puts it right back to the prior value: 2023-11-06 12:44:36,268 Thread-15645 udi_interface DEBUG venstarapi:getThermostatState: in API getThermostatState()... 2023-11-06 12:44:36,269 Thread-15645 udi_interface DEBUG venstarapi:_call_api: HTTP GET http://10.10.60.104/query/info data: None 2023-11-06 12:44:36,417 Thread-15645 udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0} 2023-11-06 12:44:36,417 Thread-15645 udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0} 2023-11-06 12:44:36,419 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in GV0's value 2023-11-06 12:44:36,419 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in GV0's value 2023-11-06 12:44:36,420 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in ST's value 2023-11-06 12:44:36,421 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE Reporting set CLISPH to 70.0 to Polyglot 2023-11-06 12:44:36,422 Thread-15645 udi_interface.node DEBUG node:reportDriver: Updating value to 70.0 2023-11-06 12:44:36,423 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLISPC's value 2023-11-06 12:44:36,420 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in ST's value 2023-11-06 12:44:36,421 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE Reporting set CLISPH to 70.0 to Polyglot 2023-11-06 12:44:36,422 Thread-15645 udi_interface.node DEBUG node:reportDriver: Updating value to 70.0 2023-11-06 12:44:36,423 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLISPC's value 2023-11-06 12:44:36,424 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLIMD's value 2023-11-06 12:44:36,425 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLIFS's value 2023-11-06 12:44:36,426 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLIHCS's value 2023-11-06 12:44:36,424 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLIMD's value 2023-11-06 12:44:36,425 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLIFS's value 2023-11-06 12:44:36,426 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLIHCS's value 2023-11-06 12:44:36,427 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLIFRS's value 2023-11-06 12:44:36,428 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLISMD's value 2023-11-06 12:44:36,429 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLIHUM's value 2023-11-06 12:44:36,430 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in GV1's value 2023-11-06 12:44:36,431 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in GV2's value 2023-11-06 12:44:36,427 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLIFRS's value 2023-11-06 12:44:36,428 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLISMD's value 2023-11-06 12:44:36,429 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in CLIHUM's value 2023-11-06 12:44:36,430 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in GV1's value 2023-11-06 12:44:36,431 Thread-15645 udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE No change in GV2's value As you stated, I do not find those error messages in the logs. While repeatedly testing right now while watching the logs on a different computer, sometimes I see the value temporarily change in the UI then revert, sometimes I don't see it change- given the frequency of shortpolling I think it depends on when the command comes in in relation to the polls. Similarly any changes to schedulemode in IOX for an Explorer reverts back at the next shortpoll. Also note you ARE sending both heattemp and cooltemp at the same time. If I send a mode command, you are sending mode + both setpoints. In programs, I can properly control the ColorTouches mode and setpoints, but not the Explorers. (I created a test program with only an action statement to change the mode) 2023-11-06 14:07:12,022 Command udi_interface DEBUG venstarapi:_call_api: HTTP GET http://10.10.60.104/query/info data: None 2023-11-06 14:07:13,221 Command udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":68.0,"cooltemp":75.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0} 2023-11-06 14:07:13,221 Command udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":68.0,"cooltemp":75.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0} 2023-11-06 14:07:13,222 Command udi_interface DEBUG venstarapi:setThermostatControls: in API setThermostatControls()... 2023-11-06 14:07:13,222 Command udi_interface DEBUG venstarapi:setThermostatControls: in API setThermostatControls()... 2023-11-06 14:07:13,223 Command udi_interface DEBUG venstarapi:_call_api: HTTP POST http://10.10.60.104/control data: {'mode': 2, 'heattemp': 68.0, 'cooltemp': 75.0} 2023-11-06 14:07:13,223 Command udi_interface DEBUG venstarapi:_call_api: HTTP POST http://10.10.60.104/control data: {'mode': 2, 'heattemp': 68.0, 'cooltemp': 75.0} 2023-11-06 14:07:14,407 Command udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"success": true} 2023-11-06 14:07:14,407 Command udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"success": true} 2023-11-06 14:07:14,408 Command udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE Reporting set CLIMD to 2 to Polyglot 2023-11-06 14:07:14,408 Command udi_interface.node DEBUG node:setDriver: xa0a3c68:OFFICE Reporting set CLIMD to 2 to Polyglot 2023-11-06 14:07:14,409 Command udi_interface.node DEBUG node:reportDriver: Updating value to 2 2023-11-06 14:07:14,409 Command udi_interface.node DEBUG node:reportDriver: Updating value to 2 2023-11-06 14:07:14,416 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'xa0a3c68', 'driver': 'CLIMD', 'value': '2', 'uom': 67, 'text': None}]} 2023-11-06 14:07:14,416 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'xa0a3c68', 'driver': 'CLIMD', 'value': '2', 'uom': 67, 'text': None}]} 2023-11-06 14:07:14,542 MQTT udi_interface.interface INFO interface:_message: Successfully set xa0a3c68 :: CLIMD to 2 UOM 67 2023-11-06 14:07:14,542 MQTT udi_interface.interface INFO interface:_message: Successfully set xa0a3c68 :: CLIMD to 2 UOM 67 Nothing happens at the Thermostat. If I post the same command manually: POST http://10.10.60.104/control HTTP/1.1 Content-Type:application/x-www-form-urlencoded mode=2&heattemp=68&cooltemp=75 instantly the Explorer thermostat responds. The tempunits is set to 0- everything is in Fahrenheit. The delta is appropriate. If I send the same command as above with the tenth degree decimal place specified (78.0) it still responds properly. I have no setting lock on any thermostat. Re: command inconsistency in my report: Might have copied the wrong line back in as an example as I sent commands well before I started drafting the report. Apologies for the confusion. Given the behavior I'm seeing, I'm thoroughly confused. But I am sure I'm testing the correct thermostats by IP address and the names programmed into the thermostats match the IOX UI, as do their settings when queried. Their IP addresses match my DHCP reservations. I can send an API command and then watch the IOX report change to match at the next poll as well as do this while standing right in front of the thermostat I'm controlling. Since the first post I set up SkyPort and enrolled the thermostats- I can control them at will via their service. I'm on version 3.0.11 of your nodeserver.

Adding a bit more detail: I can directly set heat/cool setpoints via a direct API call and they are instantly reflected in the TSTAT UI and API query. They appear in the IOX UI as well after the next short poll as well. curl http://10.10.60.105/query/info {"name":"Bedroom","mode":1,"state":1,"activestage":1,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":69.0,"heattemp":71.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":40,"availablemodes":1} POST http://xxx.xxx.xxx.xxx/control HTTP/1.1 Content-Type: application/x-www-form-urlencoded mode=1&fan=0&heattemp=64&cooltemp=82 curl http://10.10.60.105/query/info {"name":"Bedroom","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":69.0,"heattemp":69.0,"cooltemp":82.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":39,"availablemodes":1} So at least confirming it's not a network/Venstar API/Thermostat error.

Hello, Just getting started with changing over all my thermostats to Venstar to use this nodeserver. I have both the colortouch T7900s and the Explorer T3950IAQs, both of which are noted as supported by the nodeserver. All are online and connected to the nodeserver (direct IP address in the nodeserver configuration) and status changes by the thermostats are picked up by the nodeserver and displayed in the IOX admin console. If I press increase or decrease setpoint in IOX via the button or via a program action, or directly set a setpoint value via program, it works with the color touch thermostats. The same action does not work with the explorers. If I directly program a setpoint value, it changes in the IOX UI but not the thermostat display. With the next poll, the IOX UI reverts to the thermostat setting. Same with increase/decrease setpoint button pushes. The thermostats are all newly installed (this week), using http protocol not https, and are again, all online and connected to the nodeserver. They're all on the most recent firmware. The other oddity I've noticed is schedule mode. I have all thermostats set to non-programmable and "program off" is shown on the thermostats. Via the API info the thermostat reports schedule 0 and schedulepart 0. Yet the IOX UI keeps showing an active schedule. If I press the schedule mode off button, it briefly reports "inactive" but then quickly reverts to a time of day such as "morning" - yet the API still reports 0/0. The nodes for the color touch thermostats correctly report inactive schedule mode. Perhaps there is an issue with parsing the API response? The responses are not identical, however parameter names are consistent when included. Color Touch: curl http://xxx.xxx.xxx.xxx/query/info { "name":"Kitchen", "mode":1, "state":0, "fan":0, "fanstate":0, "tempunits":0, "schedule":0, "schedulepart":255, "away":0, "spacetemp":70.0, "heattemp":64.0, "cooltemp":80.0, "cooltempmin":72.0, "cooltempmax":99.0, "heattempmin":35.0, "heattempmax":78.0, "activestage":0, "hum_active":0, "hum":44, "hum_setpoint":0, "dehum_setpoint":75, "setpointdelta":2.0, "availablemodes":0 } Explorer curl http://xxx.xxx.xxx.xxx/query/info { "name":"Bedroom", "mode":1, "state":1, "activestage":1, "fan":0, "fanstate":0, "tempunits":0, "schedule":0, "schedulepart":0, "away":0, "spacetemp":69.0, "heattemp":71.0, "cooltemp":78.0, "cooltempmin":72.0, "cooltempmax":72.0, "heattempmin":78.0, "heattempmax":78.0, "setpointdelta":2, "hum":40, "availablemodes":1} Any help would be appreciated.