SJK

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.

Neat- so you just stick them on the wall somewhere they can blast to the head unit and then it sends out the commands? Did the "Dry" mode ever show up in the nodeserver? Are you able to control enough of the functions beyond just on/off/temp to make it worthwhile? The Air looks nice- pairs the unit with a motion sensor for occupancy control (but of course I've got that with Elk already). A bit confused how you're using the ecobees as well. Is that controlling the minisplits too or is that hooked to your conventional or "main" heating unit elsewhere so you can use the ISY for integration of a hybrid system?

ok thanks. From perusing the code, seems like you're leaning on https://github.com/CCecilia/Roku-Scanner for the discovery. Wondering if I could rewrite the nodeserver to use config variables to essentially create the output of a discovery instead of running one. After all we know the serial #s and IP addresses. Channels are another thing though. I'll have time to do that long after these devices are obsolete.

I have Z-wave at one of our commercial properties- it was a royal PITA to work with- but I started back when we were on the 300 series boards and the old ISY-99i. I recently redid it all now that I've migrated that property over to the eISY with the new Zmatter dongle- still a work in progress. So willing to give it a try at home, but this would be the only Z-wave devices in the home. Plus I've never found any pretty-looking Z-wave T-Stats! The venstars have local control - so that's the big selling point for me. They aren't much more expensive than the ecobee lites. I can get 2 Honeywell T9s or ecobees (any model) for $100 off each from my utility but of course will eventually need more (this is stage 1 of a 3-part HVAC install- 6 zones now, 2 more later). @dbwarner5 How do you like the ecobees? Not interested in the security features- not really the Siri or Alexa bits either- so the lites are likely to be the ones I'd put in in most zones if I went that route (except a few where I wanted a remote monitor for averaging over a large area or attached bathroom). I've seen good reviews and bad reviews about them being over-complicated. I'll note that a decade ago I used a Honeywell Z-wave attached to an ISY-99i in a single-zone setup and the Honeywell unit worked well when I could get it to connect (external antenna setup/sole device). Dead simple. Ugly T-stat though, that's for sure. Not a big deal in the hall above the basement stairs, but for this home they'll be in every bedroom and common areas. @bpwwer Thank you for that link- but it appears to apply to the evolution system which I believe is not the same. At least it's marketed differently and the hardware under that line is not compatible. It's very high efficiency stuff but limited in size/piping/zones so I cannot use it in my application. I will ask the installer to check with the manufacturer if their add-on wifi system connects to the same servers/uses the same API on the backend.

About $1600 for Tstats plus whatever the adapters cost. This house is huge, old, and, relatively uninsulated (aside from 13" of brick exterior) - long term project to weatherize of course. Given the cost of my utility bills, active management can provide me very significant ROI in all seasons plus reduce our energy footprint for the sake of emissions reduction. The only T-stat nodeservers I can find are ecobee, venstar, and Honeywell home. Mentioned Honeywell home above (I have one for my existing gas boiler). Nice but overpriced for this setup and won't use any of those features other than direct external control (and relies on TWO cloud solutions chained together to function). Happy with them for simple management of my commercial properties which are schedule-based. Not the best for home use in this situation. But again, ANY of those options are the 24v adapter plus a 3rd party Tstat setup somehow hooked to IoX either via a nodeserver or a Zwave/Zigbee T-Stat. Carrier/Bryant has a wifi solution (inbuilt into some of the heads, as a separate device add on for others) which connects to a phone app and presumably their cloud. I don't see a nodeserver for that. That would be the only way I can see, unless someone has found a different solution, to avoid the 24v adapters and external thermostats. Anyway, not looking to fiddle with HVAC all day on my phone- looking to automate it so I don't have to touch it at all but it responds to the conditions programmed into IoX already with home/away/windows/room occupancy/season/time of day/status of gas boiler/external temp & humidity/etc. And they also resell ecobee as their "intellisense" option- which as best I can gather (waiting on mfr info) is just the ecobee tstat and the 24v interface. Standard out of the box solution for minsplits is a handheld remote for each zone/head/room. I cannot find any way to get control of the zone with IoX using those- cannot find info on if they are IR/Bluetooth/whatever or if the protocol is open enough that commands can be sent to the head from another device (IoX via Zwave IR blaster, network, etc.) These are residential units, not things designed for commercial centralized/networked control (and those do not meet SEER/HPSF targets for residential incentives). Hence the query if anyone has any experience with these. If I find no other elegant/inexpensive solution, I will likely end up using the 24 interfaces for each room with a Venstar Tstat as those have local API control as an option and there's a maintained nodeserver available for that.

Anyone have these devices and figured out how to interface them with IoX/Polyglot? I'm about to replace part of my HVAC system with some high-efficiency variable speed Bryant ductless minisplits. I've already got occupancy sensors and temp sensors in most rooms and I want to add additional levels of automation than you'd get from the handheld remotes. Time of day changes, automated setbacks based upon home occupancy, room occupancy, season, external temp, etc. Also since I'm still in a hybrid system with and old hydronic boiler for the winter I need some more intelligent control than exists on-device itself to coordinate whether or not there's any supplemental base heating being provided. I have my rep inquiring with the manufacturer, but was looking for field experience if anyone had any. There is a 24v control kit, but then I'm adding one to each unit (8 of them so far, more to come) with a dedicated Z-wave or Zigbee room thermostat and all the remodeling that comes with it so I can manually tell it which mode and which temp to use, sort of neutering it's inbuilt functions and that's a lot of extra expense (and programming) if there's an easier way. There's also a Wifi option- but who knows what custom command set that uses. I didn't see any nodeserver out there so far for what its worth. And while I currently have the Honeywell home/Residio Ttats for my old hydronic (and at my commercial properties) I haven't been able to get that to work within IoX yet with the nodeserver. Not a real fan of a cloud service for HVAC anyways especially one running on the graces of that nodeservers' free cloud server to interface. Thanks.

I've installed the Roku nodeserver and it's not finding my devices. My first thought is that it's limiting its search to as /24 subnet matching the polisy. I have a segmented network with the media services on their own subnet. Currently I'm not using complicated VLAN rules to restrict traffic, but that's the plan (when I can get SONOS to play nicely with that.) Security devices and automation on one, IOT on another, trusted devices, media devices, servers, etc. all segregated. Am I correct in my assumption and is there any way to specify the IPs to use? I have DHCP reservations for these devices so it's not like they will change once discovered. Thanks.

worked this week- no new steps but noted there was a new set of package updates taken during the upgrade step. So perhaps a recent code change worked. Or elves.

Any idea what I should be searching for? I don't see anything unusual or any specific references to PG3x- only the usual log entries. I've tried debug logging too but that seems to reset to info after reboots.

No idea what was different this time but on the 4th cycle I get this: /usr/local/etc/udx.d/static/udx_startup.sh: running pg3 in pg3x mode . However - I'm still seeing in the UI PG3, not PG3x, and still logging in with PG3 credentials, not IoX credentials. And UD mobile is still complaining that the notifications feature requires migration from PG3 to PG3x. (But all along I am able to use network resources to send notifications to UDMobile from Polisy, just like I can from eISY)

I'm not sure I'm getting this right, but I believe I'm following the instructions. (my eISY is on PG3x). My polisy is on 3.1.23. IoX is on 5.6.2. I've hit the upgrade packages button, waited a long time (hours- walked away). Rebooted. IoX seems fine, Polisy is still on PG3, 3.1.23. I've used the rest call https://polisy:8443/rest/pg3x.enable. more than once (not in a row). I've not renamed the Polisy, I believe that is the correct internal network URL (dropped .local) as that's the URL in the IoX finder to log into the admin console and how I'd access PG3 (https://polisy:3000). As above, no response in the browser (XML has no stylesheet message/blank page)- but not any error message/invalid URL response either. Logging into the PG3 interface- all nodes are connected/running. Done the reboot cycle after that too- nothing seems different. no pop-up messages. Still PG3, 3.1.23. Starting from the basics- is the REST request/response code logged anywhere for me to validate that I am triggering the pg3x.enable script? I can't seem to find any log entry anywhere. The only useful log entry. I can find is the /var/udx/logs/log file entry stating "no packages need updating." Thanks.

Thanks- what was done, and did not work. Currently rebuilding from scratch as nothing works.

@lilyoyo1 yes @Techman I'm experiencing essentially that - the only way I've gotten anything to work is to DELETE the device and start again- which I don't understand why that should be the case. As I've said a few times now, I've checked the ISY links table which shows what I would expect AND the PLM links table AND the device links table- the OLD PLM is NOT present, but the NEW is. What is exactly what I'd expect after replacing the PLM and reprogramming it from the ISY and restoring the devices with the ISY data. Again, I've also factory-reset some devices and reprogrammed them with the ISY data and that didn't work either. And after doing this I have to rebuild every scene because the device was removed (and the scene doesn't exist outside the ISY anyway) AND touch every line referencing an Insteon device in every program for them to work. (Even though the address is the same and properly appear in the code, the programs don't run). So basically what is happening here is that if my PLM ever dies and needs to be replaced with a different address (i.e. not a cap replacement), I cannot get my complex system back without rebuilding it from scratch as a restore won't work. That just doesn't seem right and doesn't match with the wiki instructions https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:File_Menu#Restore_Modem_.28PLM.29 which indicates what I've observed when performing "restore PLM" And then when performing "restore devices" When completing though, the admin console does not close and the ISY does not reboot. However, rebooting it myself didn't change anything. The UI has all the new data but nothing works. It's the scenario described under delete PLM, which is NOT what I did. The backup used was from prior to replacing the PLM and I followed the instructions from the wiki above. the eISY never used the old PLM and the polisy never used the new PLM.

Right- I did restore PLM- and verified that the devices in each system has the correct PLM address linked to it (devices associated with polisy - old PLM address, devices "moved" to eisy- new PLM address and NOT old) - and that the PLM has a link to the device in its table as well.

Yes, the UI and firmware are both 5.6.0. Yes, v9e in the PLM info/status screen- Revision 2.6 on the hardware itself. (1.26 was a typo sorry) I took a backup of the polisy and restored that to the eISY before removing devices/programs/scenes as noted so each device is only represented on one system. Then reprogrammed PLM and devices so they are linked to the eISY not the polisy, and did the same on the polisy to ensure everything was removed. The Elk is a bit irrelevant here- I'm using nodeservers for the Elk - and yes, each IoX (polisy and eisy) are associated with the polyglot server running on the polisy. The Elk nodeserver is installed into each IoX via their respective dashboards, and both the eISY and the polisy see any Elk events immediately (armed status, door violation, etc). That was test #1 prior to even going down this road as I obviously need one comprehensive home security system but both IoXes need to know what's going on in the house overall despite only controlling one part of its lights and HVAC etc. (Elk isn't a scene controller- I use programs and variables for interfaces with anything not purely Insteon).

This week I finally split my Insteon network in half. I had hit the 1024 node limit due to my scene plan. It's not going smoothly and I'm not sure what I need to do to fix it. I have a Polisy attached to a USB PLM which was previously running everything. I backed that up and copied it over to my new eISY with one of the new USB PLMs that just came out (v1.26). I then deleted scenes and devices (and programs) related to the 1st/2nd floors of my home from the Polisy, leaving 3rd floor/basement and exterior items alone. I did the reverse on the eISY- deleting everything except 1st/2nd floor. I associated the new eISY with the polisy server on the older polisy (only need one running) and set that up with nodeservers and configured all that. So far so good- both polisy and eISY see the status of my Elk system and all the relevant nodeservers, etc. My polisy and old insteon network works fine. A few devices needed restoring but that's about it. The eISY not so much. I programmed the new PLM via the eISY - it is listed as connected and shows the correct address (differs from the Polisy PLM) and I can control individual devices from the IoX console. I also used the restore devices function (a few times) to restore links to the new PLM. Also tried restore PLM multiple other times. Also rebooted, etc. I'll note I'm on 5.6.0 on both polisy and eISY and this house is currently Insteon-only. Status does not get reported back to IoX. If I adjust a device from the console, the device responds. If I manually adjust a device, IoX doesn't pick that up. I have to query the device to get the correct status. If I pick an individual device and look at the device links table, the PLM address is there (and importantly the old PLM address is NOT). The device link table matches the ISY link table. Same with the PLM links- the device is there. Scenes don't work either- unless I manually go to the scene in the admin console and update the Insteon on level for each device in the scene (so that it re-creates missing links). Thought that would have been covered by the replace/restore process. Seems like the scenes contained in the ISY didn't get programmed into the PLM. Everything is listed correctly as controllers/responders with the appropriate scene setting (on level/ramp, etc) but they don't function until I touch each and every member of scene to reconfigure them. It's going to be a massive pain to reprogram them all manually- each time I update one device, the highlighted member changes (member list reshuffles) and I lose track of which members were re-associated. And then again, after reprogramming, they function, but no status report for scene members- the scene appears to be off from the standpoint of the admin console (unless I turned it on via the admin console). Doesn't appear to be communications issues- responses to commands sent via the admin console are instantaneous and smooth. I don't see communication failures in the event viewer. Seems to be the devices just don't I've also tried factory-resetting devices and then restoring them again- no difference. Can control, scenes aren't restored, and status is not reported back to eISY. I shutdown the polisy and unplugged the old PLM while I troubleshoot. I've cleared my Java cache/reinstalled the application, etc. Any ideas? I know this is a bit out of scope of normal usage but seems to me it would be a similar procedure as for a failed PLM. Can anyone confirm that status properly reports back to IoX on one of the new Insteon v1.26 USB PLMs?

I tried- unacceptable delays and complications. I have a lot of routines triggered by programs and time-of-day setups using scenes and that's exactly why I'm hitting the limits. Using programs to trigger lights doesn't work. The popcorn effect is intolerable. I'm also not willing to abuse the EEPROMs by reprogramming the on levels per room 6x a day. The only real solution for a whole-house buildout is 2 ISYs and 2 PLMs, one on the main floors, the second exterior/utility/less used areas.

Update- posting this for the benefit of those who may be searching for similar issue in the future. 994i/Polisy/eISY all have 1024 device/scene/folder limit. Not there- I am halfway. Programs/program folders not a factor. Insteon PLM link DB- also in mid-500s, not at ~950-1000 link limit (I've seen various limits) However, Insteon has a 255 scene limit. I'm right against that limit. So off to figure out how to partition my system between 2 IoX system and PLMs with one Polyglot and one Elk.

Error log ISY Error Log.v5.5.4__Thu 2023.01.26 07.24.51.txt

A bit more detail: I did see https://forum.universal-devices.com/topic/31899-cannot-create-a-new-scene-or-folder-in-isy99i/#comment-3064 and am quite sure that is not my issue since I'm on a Polisy and as above don't have some crazy amount of folders/scenes/devices where I'd have simply run out of resources. I cannot delete a scene either. Since I'm still building out this home, I have created some empty scenes as placeholders for known future devices or functions. I tried to delete one of them to again confirm that it's not a limit issue and I get an error "Request Failed." Certainly seems to be a communication/authorization issue. But again, ISY is functioning normally and I can turn on/off scenes manually via the ISY and programs are doing their thing including responding to manual keypresses at the switch. So my ISY and PLM are communicating properly. I don't have stuck programs or retries/device traffic. The event log is quiet. I can adjust scene settings- adjust on levels and add/remove devices from an existing scene. So next test- unplugged the PLM to reboot it as it seems to have something to do with ISY/PLM communication (to create a scene, IOX needs to write it to the PLM, correct?) No improvement. Still getting the error- now seeing this: Additional thought- I turned off writes to devices which should allow me to stage changes in IOX before writing them out to the devices (including PLM?) and I still got the error. So looking more and more likely to be internal to the IOX software. ISY Topology.v5.5.4__Thu 2023.01.26 07.25.16.html