@Mantorok so sorry, big facepalm again. I thought restarting HA would be effective as I’m running Homebridge through Portainer installed on my HA.
Restarting within Homebridge seems to have fixed the MQTT issue as well as the issue you listed above. Thanks for the (amazingly) prompt reply!
Thanks for expanding out the logging @Mantorok. I increased the the polling to 60secs, and it looks like the TCP Open/Close connections are consistent every poll with “Get Characteristics”. 30secs may have been too frequent. What do you have your polling set to?
I thought I was on a roll going a whole week without the ECONNREFUSED issue. Then it happened three times in 24hrs. I’ll try the settings you recommended, but I’d like to get more visibility in to the logs to troubleshoot, but they’re a bit noisy atm. Do you have configurable logging levels built in, or is permanently set to INFO? What would be great is to have MQTT publish a topic when the WiFi module is offline!
Hi @David_M, the getting/setting characteristics logs are caused by HomeKit making a request. The Regular interval polling for MQTT should show a different log message. I don’t actually use the MQTT functionality so don’t have polling enabled.
In my own testing I find the likely cause of the ECONNREFUSED is when a TCP connection is opened too soon after it was closed. Try increasing the Close Connection Delay first to see how it goes.
I’m currently in the process of converting the plugin to Typescript. As part of that I’m switching to using Homebridge’s own logging methods which are colour coded (red for error, yellow for warning etc) which may make it a little easier to read. Also, I wouldn’t bother turning on debug logging. It’s more for my benefit so I can see the call stack while I’m debugging. I will reduce this type of logging in the next version.
I’ll see about adding a new MQTT topic too for reporting connection errors. Should be doable.
Hey @Mantorok - Think I may have found the cause of my irregular timeouts. I still had the Home Assistant integration configured. After I removed this, the characteristic logging stopped. This is odd, as I would have thought that integration would only be polling Homebridge attributes and had nothing to do with causing the plugin to poll the wifi module. However, I was noticing the timeout would occur when the temperature was set first thing in the morning by an MQTT publish payload, which probably coincidently occurred during the characteristics ‘get’, causing the ECONNREFUSED. Touch wood, it’s been stable for two days.
I was only using the integration to report the overall heat_cool_state. I think you may have been using “ZUS”: {“AE”: “N”, “MT”: “999” } for determining if the furnace was on/off. With the MQTT subscription I can get the heating state of each zone (per the little flames below), so I should be able to create a template to report the furnace state.
Yeah, that would make sense. If the HA integration requests an update of Plugin’s accessories (ie. thermostat, switches etc) then it would trigger the TCP connection to open so it can obtain the latest status from the WiFi module.
Did you end up increasing the delay setting? You may still encounter the ECONNREFUSED error from time to time if the plugin opens & closes the connection often.
The heating/cooling state is determined by a bit of logic, but for Single Temp Set Point it uses HGOM.GSS.HC (or CGOM.CSS.CC for cooling). This is used for the Thermostat accessory. For the zones it uses HGOM.ZxS.AE which is used in the MQTT topic hvac/action/get
Brand new plugin is now available: https://www.npmjs.com/package/homebridge-rinnai-touch-platform. This is a replacement for the old homebridge-rinnai-touch-plugin which I’ll deprecate. The new plugin was created from the official homebridge-plugin-template and has been completely rewritten in Typescript.
The latest version (3.0.1) contains some enhancements to MQTT and logging. A new MQTT format is now available for obtaining the status of the TCP connection. Debug logging is no longer available as an option in the settings but can be enabled by starting Homebridge in Debug mode.
For a smooth migration to the new plugin I would recommend that before installing this new plugin you uninstall the old one first and remove the cachedAccessories file from the ./homebridge/accessories folder. There’s no need to delete the settings in the config.json file which should work with the new plugin.
As this is quite a big change please treat this as a beta version for now. If you find any bugs please let me know and I’ll attempt to fix ASAP.
Hey @Mantorok - I stood up a second dev homebridge container to test out the new version. So far so good. Seems to be behaving. I made sure I configured it via the UI with a blank config file also.
I noticed the connection/status/get topic publishes an open and close state with each TCP connection. Is there another state when the connection is refused?
Thanks, again!
Thanks @David_M for the feedback.
Yes, there’s a 3rd state error that should be published when things like ECONNREFUSED occurs.
Hey @Mantorok… Might have found a bug or maybe a misconfig. I’ve noticed the regular MQTT publishing doesn’t seem to be working. My config is below. I originally configured it all from scratch via the GUI and specified 60 seconds in the frequency field, but noticed it wasn’t added to the config. I added it manually, restarted, but still doesn’t work.
MQTT: Publish Event: Scheduled Interval event is logged every minute, however nothing is sent to the broker.
I’m trying to ensure that when the temperature is changed manually on the thermostat, the new temperature is published, which will keep things in sync.
"controllerType": "T",
"zoneType": "S",
"showFan": true,
"showAuto": true,
"showAdvanceSwitches": true,
"showManualSwitches": true,
"closeConnectionDelay": 1200,
"clearCache": false,
"mqtt": {
"host": "mqtt://x.x.x.x",
"port": 1883,
"username": "username",
"password": "password",
"topicPrefix": "rinnai",
"formatHomeAssistant": true,
"formatConnection": true,
"publishStatusChanged": true,
"publishIntervals": true,
"publishFrequency": 60
},
"platform": "RinnaiTouchPlatform"
}
Hi @David_M, the default publishFrequency is 60 seconds so that might be why it wasn’t added to the config.json file when entered via the GUI. So if it’s explicitly set to 60 or not specified at all the plugin should use 60 second intervals.
When you see the MQTT: Publish Event: Scheduled Interval event in the log do you also see the TCP connection open shortly after it? This would indicate that it is attempting to fetch the current status from the WiFi module.
Also, when you say you manually change the temperature on the thermostat are you talking about the physical controller on the wall (NC-6) or a virtual thermostat in the iOS Home app or HA?
@Mantorok - Nope, no connections are made and I’ve watched the broker for new events. I fired up the old version also to check, and although it opens a connection, it doesn’t publish any states. I’ve got a feeling this hasn’t worked for a few versions.
v3.0.1
[7/23/2020, 9:10:20 AM] [RinnaiTouchPlatform] MQTT: Publish Event: Scheduled Interval
[7/23/2020, 9:11:20 AM] [RinnaiTouchPlatform] MQTT: Publish Event: Scheduled Interval
[7/23/2020, 9:12:20 AM] [RinnaiTouchPlatform] MQTT: Publish Event: Scheduled Interval
[7/23/2020, 9:13:20 AM] [RinnaiTouchPlatform] MQTT: Publish Event: Scheduled Interval
[7/23/2020, 9:14:20 AM] [RinnaiTouchPlatform] MQTT: Publish Event: Scheduled Interval
[7/23/2020, 9:15:20 AM] [RinnaiTouchPlatform] MQTT: Publish Event: Scheduled Interval
v2.5.2
[7/22/2020, 11:24:03 PM] [Rinnai Touch] [INFO] MQTT Publish Event: Scheduled Interval (HA)
[7/22/2020, 11:24:03 PM] [Rinnai Touch] [INFO] TCP Connection: Open
[7/22/2020, 11:24:10 PM] [Rinnai Touch] [INFO] TCP Connection: Closed
[7/22/2020, 11:24:48 PM] [Rinnai Touch] [INFO] MQTT Publish Event: Scheduled Interval (HA)
[7/22/2020, 11:24:49 PM] [Rinnai Touch] [INFO] TCP Connection: Open
[7/22/2020, 11:24:55 PM] [Rinnai Touch] [INFO] TCP Connection: Closed
[7/22/2020, 11:25:33 PM] [Rinnai Touch] [INFO] MQTT Publish Event: Scheduled Interval (HA)
[7/22/2020, 11:25:34 PM] [Rinnai Touch] [INFO] TCP Connection: Open
[7/22/2020, 11:25:40 PM] [Rinnai Touch] [INFO] TCP Connection: Closed
And yes, when the changes are made to the physical thermostat. Only when you open the Accessories tab in HB will the states change for any setting. I might be only seeing this issue now as I removed the HA integration and only using MQTT for publishing and subscribing.
FWIW - I’m up and running on the new Touch Platform (3.0.1). All smooth so far (and appoear to have exact same config as @David_M). One slight oddity is I now see two “Rinnai Touch” devices/accessories in my Home app, and both “work”. I did manually remove the accessories cache, prior to installing the new Plugin.
@David_M, yeah that doesn’t look correct. It should open a TCP connection. One thing to keep in mind is that the plugin will only publish a topic if its payload has changed since the last time it was published. You won’t always see a publish entry in the log after the TCP connection is opened.
@FrontBottom, that does seem odd. If you restart Homebridge does it fix it? After the restart check the logs for messages that look like Configure Thermostat U How many do you see?
Another possible fix could be to force quit the Home app on your phone, delete that accessory cache file again and restart Homebridge. In this case you should see Add Thermostat U in the logs. There should be just one.
That fixed it - restarted HB (went into boot loop so I deleted the accessories cache again) and it cleaned up the duplicate. 
@FrontBottom, glad to hear its fixed.
@David_M, version 3.0.2 has been released which should fix the HA Interval publishing bug.
Great service! Issue is fixed. Just seeing the connection status published each poll, which is expected. Probably don’t really need to see the Open/Close from my perspective. I haven’t subscribe to this topic yet, as it will add a lot of unnecessary noise to HA. The ‘error’ state will definitely be useful though. Any one else using the Open/Close state for tracking polling?
[7/24/2020, 10:35:56 AM] [RinnaiTouchPlatform] TCP Connection: Open
[7/24/2020, 10:35:57 AM] [RinnaiTouchPlatform] MQTT: Publish: rinnai/connection/status/get, Payload: open
[7/24/2020, 10:36:03 AM] [RinnaiTouchPlatform] TCP Connection: Closed
[7/24/2020, 10:36:03 AM] [RinnaiTouchPlatform] MQTT: Publish: rinnai/connection/status/get, Payload: closed
[7/24/2020, 10:36:56 AM] [RinnaiTouchPlatform] MQTT: Publish Event: Scheduled Interval
[7/24/2020, 10:36:56 AM] [RinnaiTouchPlatform] TCP Connection: Open
[7/24/2020, 10:36:57 AM] [RinnaiTouchPlatform] MQTT: Publish: rinnai/connection/status/get, Payload: open
[7/24/2020, 10:37:03 AM] [RinnaiTouchPlatform] TCP Connection: Closed
[7/24/2020, 10:37:03 AM] [RinnaiTouchPlatform] MQTT: Publish: rinnai/connection/status/get, Payload: closed
@David_M, I’m guessing you would want to know not only when the TCP connection is in “error” but also when it is not longer in that state. That’s the main reason I added the other 2 states so you know when it recovers from the error.
One option could be to split up the 3 states into their own topics which are either true or false. For you you could just subscribe to the connection/error/get topic so you know when it’s in error or not.
How does that sound?
EDIT: An alternative is to merge the open and closed states into a single one like ok which indicates that the TCP connection has no problems. This would be easier to implement
Hey everyone,
First up, thanks for making this plugin, looks amazing and I’m really keen to give it a shot.
For us less experienced HA users, how do you install it? I can’t seem to run the install commands when Ssh-ing in…
I am running bass and have the HomeKit integration, but I imagine I’m missing something or too dumb to figure out the obvious…
Thanks so much if anyone has a minute to assist…
I’m not - but haven’t put any thought into it yet!