hart2hart

I have the keypads that include the motion detector and the ratgdo documentation mentions some support for them. Does the node server support their use? It would be very handy and likely replace the need for an old battery powered insteon MS.

Thank you, @Goose66 I’m looking forward to arrival ratgdo devices so I can put it all in place.

Upgraded. Thanks UDI!

@Goose66, thanks. After changing sensor type setting on the physical thermostat from Outdoor to Remote and doing testing all is working well.

I’d guess your IP setup has an issue. Specifically, your DNS server IP addresses are not set up correctly so rpi can’t resolve automationshack.com.

Adding a bit more information... The log entry about "Outdoor" has now changed to "Remote" after I changed the Sensor Type. It is updating the NS with the correct temperature. Does the CoolTouch API designate the sensor by type -- appears so from log? I'm a little surprised that they would do this as you can only have one wired sensor, but then I recall they added a WiFi sensor so maybe that's why the type is so important. I've had a WiFi sensor still in its box for a few years. If I can find it do, we want to experiment with adding it to thermostat and see what types it can be set to... To me, clearly now me changing the Sensor Type from Remote to Outdoor was the root cause of my issue but its discovery will likely add to the cause. 2023-12-28 06:53:03,643 Thread-3455 udi_interface DEBUG venstarapi:_call_api: HTTP GET http://192.168.1.183/query/sensors data: None 2023-12-28 06:53:03,653 Thread-3455 udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"sensors":[{"name":"Thermostat","temp":72.0,"hum":40},{"name":"Space Temp","temp":72.0},{"name":"Remote","temp":33.0}]} 2023-12-28 06:53:03,653 Thread-3455 udi_interface.node DEBUG node:setDriver: c0a801b7_s0:Thermostat No change in ST's value 2023-12-28 06:53:03,654 Thread-3455 udi_interface.node DEBUG node:setDriver: c0a801b7_s0:Thermostat No change in BATLVL's value 2023-12-28 06:53:03,654 Thread-3455 udi_interface.node DEBUG node:setDriver: c0a801b7_s1:Remote No change in ST's value 2023-12-28 06:53:03,654 Thread-3455 udi_interface.node DEBUG node:setDriver: c0a801b7_s1:Remote No change in BATLVL's value

You can't name it in the thermostat. All you can do is pick a type: o Outdoor o Remote o Supply o Return It's only been a little while since I made the change I mentioned so should have recalled it better. Anyways, thinking it was originally set to Remote at the time of discovery and I "corrected it" and set it to Outdoor which is where the sensor was and is located. I just reset it to sensor type of Remote and the NS appears to be getting the correct temp now -- I'll have to wait to see if it changes with as temp changes to be sure. Is there any way to confirm it was originally Remote at time of discovery and that my changing it to Outdoors created this issue. The thermostat shows the Outside Temp at a nearby weather reporting station unless the sensor is set to Outdoor. When set to Outdoor, the thermostat displays the sensor reading as outside in climate displays which is why I adjusted it. The point was so I could quickly see the outside reading on thermostat face very easy to confirm some programming actions based on outdoor temp. Additionally, and in some cases more important is that my true local temp is usally 2-4 degrees off from distant official weather stations like at the Nashville Airport. I'm wondering if there is an issue when selecting the sensor type of Outside instead of Remote in that it does something different with the NS. I renamed two other remote sensors on the other thermostats, and they continue to register correctly. I just reviewed my topology listings that I save after all changes and the name always shows Outdoor Temp Sensor. Again, I think, I changed the type and not the name. Again, Thanks for looking at this and hoping it means new knowledge of the NS related to the wired sensor.

@Goose66 sorry but I’m lost again. All the names for the node in IOx AC and PG3x Nodes are showing as Outdoor Temp Sensor. Where are you seeing Outdoor? In retrospect, I do recall trying to give it that name in AC and then going back to the original name in same session. I see the following in the log but can't find a place to rename it. 2023-12-27 18:20:24,517 Thread-44 udi_interface DEBUG venstarapi:getThermostatState: in API getThermostatState()... 2023-12-27 18:20:24,518 Thread-44 udi_interface DEBUG venstarapi:_call_api: HTTP GET http://192.168.1.183/query/info data: None 2023-12-27 18:20:24,521 Thread-43 udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"sensors":[{"name":"Thermostat","temp":71.0,"hum":47},{"name":"Space Temp","temp":71.0},{"name":"Outdoor","temp":49.0}]} 2023-12-27 18:20:24,522 Thread-43 udi_interface DEBUG venstarapi:getRuntimes: in API getSensorState()... 2023-12-27 18:20:24,522 Thread-43 udi_interface DEBUG venstarapi:_call_api: HTTP GET http://192.168.1.183/query/runtimes data: None 2023-12-27 18:20:24,545 Thread-44 udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"name":"Great Room","mode":1,"state":0,"fan":0,"fanstate":1,"tempunits":0,"schedule":0,"schedulepart":255,"away":0,"spacetemp":71.0,"heattemp":71.0,"cooltemp":73.0,"cooltempmin":35.0,"cooltempmax":99.0,"heattempmin":35.0,"heattempmax":99.0,"activestage":0,"hum_active":1,"hum":47,"hum_setpoint":48,"dehum_setpoint":99,"setpointdelta":2.0,"availablemodes":0} 2023-12-27 18:20:24,546 Thread-43 udi_interface DEBUG venstarapi:_call_api: HTTP response code: 200 data: {"runtimes":[{"ts":1703203200,"heat1":351,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703289600,"heat1":300,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703376000,"heat1":162,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703462400,"heat1":68,"heat2":0,"cool1":70,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703548800,"heat1":9,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703635200,"heat1":191,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703701223,"heat1":361,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0}]} 2023-12-27 18:20:24,546 MQTT udi_interface.interface INFO interface:_message: Successfully set c0a801b7 :: GV11 to 0 UOM 25 2023-12-27 18:20:24,547 Thread-44 udi_interface.node DEBUG node:setDriver: c0a801b7:Great Thermostat No change in GV0's value Only thing I see in nodes is: Node Name 3 Address NodeDef Primary Node Hint Enabled Is Primary Delete Outdoor Temp Sensor c0a801b7_s1 SENSOR c0a801b7 16974592 true false Name Driver UOM Value Variable BATLVL 51 0 ${sys.node.n015_c0a801b7_s1.BATLVL} ST 17 79.0 ${sys.node.n015_c0a801b7_s1.ST} From AC:

@Goose66 , thanks so much for figuring that out and sorry as it appears I caused the issue. I’ll simply rename it back to original name.

Isylink is NodeLink and is not managed inside PG3x. You can remove it from AC Nodeservers if you’re not longer using it. I think ISY portal was original integration to Alexa. Can delete it at same way if not using.

After all, I’ve decided to install with USB wall wort. I located and 3D printed a ratgdo case on printables.com which will keep it all tidy and on top of GDO. Now just waiting for boards. Again,thanks for NS and letting me hijack this thread. Happy Holidays.

Thanks, I don’t mind soldering and will likely use the auto adapter. The ratgdo has a 3.3V port but using it appears to require 2 other wires and I only saw an example of it with a version 1.0 as documented in the designers “Solder Method”.

Thanks! Great idea. I’m guessing That auto adapter is likely a hardcoded 12V to 5V buck converter. Ive got several of the generalized buck converters so now do I set it for 3.3V and wire direct from battery to ratgdo or use your method? I haven’t pulled ladder out to look. Was locating 12V from battery on GDO difficult? EDIT: I just read install instructions from designer and it appears the 3.3V terminal is part of soldered install method. I’m going with non soldered so will likely use the auto adapter method if locating and hooking to battery is not problematic. Otherwise, I’ll just use small USB dongle.

What life expectancy of the devices? I’ve still got most original devices install at house 15 years ago. Only recently had two single band dimmerlincs that failed and I replaced. I bought a box full of dual band devices at one the last 50% Smarthome sales. I thought I’d upgrade single band with Dual Band. Replaced a few appliancelinc and lamplincs resulting in Insteon network becoming /is rock solid so never did wholesale swap of switches and other lamplincs. In fact, I’ve reused a few of the single band lamplincs and appliancelincs to replace equivalent that failed and then recapped broken for future use.

Thanks. I should have been clearer as I was thinking more of finding 12V and using a Buck converter to get it to 3.3V. That would put all of it on top of GDO. Not a big deal either was as I’ve (like most) got open AC outlet on ceiling above it. Just threw away a bunch of the small Apple usb.

Thanks to all for making this available. I just ordered two ratgdo devices. Has anyone found location on openers to pull power without need for USB dongle?

Installed!

Restarting the node sever fixed it for me.

@Goose66 Have you found anything or need anything from me?

Its not finishing the upload of 2.4m log file here or in DM.

@Goose66I've got 3 Colortouch thermostats and each of them has an external temp sensor. The Great Thermostat has stopped updating the sensor value in PG3x but it is still correct on the thermostat. The remote sensor is outside and its value is 40 F. I've restarted and stopped etc NS and the value appears to be fixed at 79 F in the NS. I've downloaded the log package and just DM'ed it to you.

Gotcha.

Log sent. Thanks

@Goose66 The error is: There was an error connecting to the Schlage service. Please check the log files and correct the issue before restarting the nodeserver.

Been getting getting error messages on node server for at least a week. Thought it might resolve but it has not.