SJK

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.

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

Within the past few days I get an error when trying to create a new scene. I do have a lot of scenes and programs, but it's only 200-250 scenes, in folders, but not too many. I'm on a Polisy- so should have plenty of RAM and not be hitting any resource limits. My PLM is connected, is functioning fine, and also only has 457 links. I'm on IOX v5.5.4 - I think I was on 5.5.2 when this started- as part of the investigation, I rebooted a few times, and hit the upgrade button which upgraded me to 5.5.4 but did not change anything. Hence why I'm not posting this in the 5.5.4 upgrade issues thread. One strange bit is sometimes I get that SSL request not authenticated message, othertimes not. In the event viewer all I see is adding scene to ISY, adding scene incomplete. Writing 0 bytes to devices. I don't see anything relevant in the error log either. Thoughts?

ok- that explains it. Still wondering what's making that function call though! If it's a node server, I should be able to stop it and then notify the nodeserver developer. @larryllix My issue isn't with approximate lat/long.

Michael- was this released yet? Yesterday I did an update via the UI, expecting that this would be out. Rebooted afterward and everything seemed fine and didn't notice any difference (I don't have the lat/long in Polisy yet)- stayed at EST with correct sunrise/sunset. So I adjusted my programs to use the inbuilt solar calculations rather than relying on sun elevation in the sun node server. Tonight I launch my ISY console to tweak some programs (my evening programs didn't run as expected) - and I'm back to Los Angeles again! Polisy UI still says Philadelphia though. Hoping this fix wasn't applied yet...

So far after the removal of nodeservers, reboot, and re-adding each back one at a time my time settings remain correct. I'll probably never figure out what was calling that service.

Thanks. Wasn't clearly thinking that one through. In general I rarely use else actions outside of "if this happens, then set variable to one/true, else set same variable to zero/false." It was an attempt to cut down on the number of programs to maintain. It works fine as separate programs, one count down, one count up. Given this is a large installation, and that I use small simple programs to set variables rather than directly manipulate devices, it gets complex fast. For those interested, the positive/negative state value is a new thing I'm trying in this house to decrease the number of state variables in play. In this case, what I'm doing is using a state variable for each room to track occupancy for lighting (there's a separate one for the HVAC delay). I have an integer variable to set the vacancy delay in seconds (minutes for the analogous HVAC variables). If the motion sensor is violated, I set the state timer to the integer declaration, a positive number. That's done in a separate simple program, one for each motion sensor. Then this timer program counts down to zero. Zero is my convention for a vacant room. So if there is continued motion, then the timer keeps resetting to the delay. Once the delay is able to reach zero, the room's been vacant for at least that length of time, and it's time to turn off the lights. A third program turns on the lights if the room occupied state variable is >0, if they're not already on. A fourth program is looking for the state variable to be zero, after which the lights are turned off (via the room scene). Yet another program determines if any lights are on in the room (as there may be multiple, and may be in a different scene) and sets a second state variable which tracks lighting on/off in the room. Sounds complex. But- there's an advantage. I can use another program to watch for manual lighting control. Turn on any of the lights in the room manually, set the lighting state as on, and set the delay timer (Same as motion, or a different value if desired). Turn the lights off manually, and set the lighting delay state variable to a negative number. That means the lights cannot turn back on until the state is zero again. Previously I had to set up a different state variable altogether to track that. That way you can turn off the lights, and take a bit to leave the room without the lights going back on as your exit motion re-triggers the lights. Here, I can even set a long off delay via a large negative assignment if a fast off is detected. That's essentially an override switch (I beep the keypad so you know you did it) that auto-expires rather than requiring you to remember to disable the override later when you wonder why the lights are not responding like you expect. So 2 state variables and two or three integer variables per room allows me to manipulate lights in a very flexible manner rather easily. As I add or adjust the system- adding switches or lights, convert more rooms to motion sensors, etc., all I have to maintain is the program which tracks lighting on/off state and the scenes themselves. If I want to adjust delays or the like, all I need to read is the integer variable page. And I can troubleshoot/visualize what is going on easily by doing something then watching the state variable page. I used to do this differently in the past with other locations. But I'm starting from scratch here, so I'm trying a new tactic with the negative numbers and force ons/offs. It's actually less state variables than the alternatives and a bit easier to parse. And I'm on polisy for this home, so I don't feel limited with processing power. Only a couple of timers are ever running at the same time- one for each occupied room per person not in the same room as others. That said, I've not had problems with using over 100 state variables on the ISY994is I've used either. Response times are good. The perceptible delay is and always has been motion sensor -> action which is because of the components involved: Elk response time/resolution, ISY notification over network via Elk M1EXP, then action. The new nodeserver-based interface is pretty good but seems to be slightly slower than the old ISY module (but that's just perception), probably due to adding another component to the chain- the nodeserver itself..

I'm not understanding why this works: If $State_X is not 0 Then Repeat While $State_X >0, Wait 1 second, $State_X -=1 as does $State_X is not 0 Then Repeat While $State_X <0, Wait 1 second, $State_X +=1 BUT $State_X is not 0 Then Repeat While $State_X >0, Wait 1 second, $State_X -=1 Else Repeat While $State_X <0, Wait 1 second, $State_X +=1 does not? The last example will count down, but not up. Thanks.

yup. Making the temp change in Polisy config doesn't work. A while (hour? went to put my kid to bed) after the change, my TZ was fixed, but my sunrise/sunset times are 3 hours off actual (Local sunset + 3 hrs) again. So any sunrise/sunset calculations in programs don't trigger correctly. My current workaround is to use the sun position nodeserver and key off the elevation parameter so set dusk, sunset, and sunrise as state variables to trigger programs. (fits anyway- most everything I am doing is llke a mini-state machine). Sent a support email.

Update/solved. Used the commandline to update instead of the UI. Reported 4 updates (even though I just did this via the UI a few hours previously) and rebooted. Restarted services and data is being saved properly, logs updating in real-time on the UI without reloading. Installed packages to be UPGRADED: isy: 5.1.1_5 -> 5.1.1_7 [udi] tcl86: 8.6.11_2 -> 8.6.12 [udi] tk86: 8.6.11_2 -> 8.6.12 [udi] udx: 2.5.1_2 -> 2.5.1_3 [udi] Number of packages to be upgraded: 4