Version 3.0.6 of the plugin has been released. This fixes a couple of bugs:
If a TCP connection throws an exception or times out the connection wasn’t being closed which could cause the plugin and Homebridge to crash
If a status JSON blob contained a sequence number of zero the message was considered invalid and was ignored.
@Rusti-gotrage, that 2nd bug could be the cause of your issue. From your logs it was looking like the TCP connection was open but you weren’t receiving any status blobs. If you’ve never sent a command to the Rinnai module (eg. from the Phone app) then the sequence number may be zero.
Ooookay… so at some point in the morning HB decided to restart itself, so I had gone from “TCP Connection: Failed. TCP Connection timed out” back to “ECONREFUSED”…
So I did the update to 3.0.6 and it still said “ECONNREFUSED”
So I rebooted the entire HASS-Pi system (including the HB Portainer).
The system came back online and HB was STILL saying ECONNREFUSED.
I checked the phone app for the Rinnai and it was showing the cloud icon, so when my wife was away from her PC making Hot Chocolate (ie; wouldn’t notice the internet dropping out), I rebooted the Router/WAP…
Now I’m back to “TCP Connection: Failed. TCP Connection timed out.”
And the phone is STILL showing the cloud icon
As a note: every time I exit the phone app, I’m jumping into the App Info and FORCE STOPPING the phone app so it’s not also communicating with the Rinnai unit…
ok - So it seems to have connected, grabbed a whole stack of data, then gone back to it’s old behaviour…
BUT - it DID connect!!
So I’m quietly rapt to the back teeth! It’s PROGRESS!!
[Update]
So it’s connected about 6 times all up in the last 75mins…
Noticed an interesting line in the last connection:
“(node:1999) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 updated listeners added to [RinnaiTouchService]. Use emitter.setMaxListeners() to increase limit”
@Rusti-gotrage, that is looking more like it. I think that during the discovery phase it added and removed a bunch of accessories which caused it to hit a limit on the number of event listeners. Maybe I should increase the limit?
Try restarting Homebridge and see if it clears the error.
The “never close connection” will actually timeout after 5 min but this is caused by the Rinnai module itself. The plugin should automatically reconnect when this happens but I am concerned that it might fail in your case as the connectivity seems a little hit and miss. Fingers crossed it will behave itself.
As for the current temperature not displaying, that is a known limitation of the Rinnai module. It doesn’t seem to emit that information for some of the older controllers like the NC-6. It seems to work fine for the Touch controller and systems that are configured as Multi-Set Point (ie. have multiple controllers).
Some people get around this by using their own 3rd party temperature sensors which can publish to MQTT. The plugin can then subscribe to those and display the current temp in the iOS home app.
Well - it seems today is my day for getting stuff working!!
Also - time for a slightly embarrassing admission… Seems part of the reason it might have been having connections issues, even when I moved to 3.0.6 and only connecting sporadically, may have been because some idiot (me!) left the NAS Docker version of HomeBridge running… which was also configured to talk to the Rinnai!
I have to say, since shutting it down, I’ve had ZERO connection issues with the HASS-Pi Portainer install of HB… (that one actually speaks to Home-Assistant - the NAS Docker one won’t!)
Now comes the fun part - the integration and automation parts!
What do people find BEST for integrating with HA??
The HomeKit Controller integration
or
MQTT???
Just looking at the MQTT Explorer, it seems like it might give me better control and reporting?
Though - I’m somewhat confused by the fan reporting… I assume the Fan is only for reporting FAN ONLY activity? and the Thermostat in the HomeKit integration doesn’t seem to allow reporting on the idle/heating/cooling state like the MQTT statuses do…?
Hey @Mantorok… I’m trying to test a recovery workflow for when the module gives an ‘error’ status and the device needs a power cycle.
If I do the power cycle, it looks like the plugin doesn’t try to reestablish the connection properly. MQTT states and topics don’t get published. Restarting HomeBridge fixes this, but ideally it is better for the plugin to recovery - also, I can’t trigger a HomeBridge restart.
Example below. Power cycled at 11:10 and the module is Found again, but all MQTT functionality stops working.
Hi @David_M, do you know if any topic states changed during the above logs? The plugin will only publish a topic if its state changes. You could test this by going to the controller and changing the target temperature or turning the heating off for example.
Also, could you put Homebridge into debug mode so we can see the extra logging info.
Hi all,
I have an issue where my Rinnai Touch wifi module is constantly dropping off my wifi,
this occurs wether it is 30 cm or 10 feet away from my wifi point.
I run a ‘Fing’ box which notifies me and logs the connection / disconnections as it occurs
and its gone offline 22 times in the last 8 hrs. when it is offline, it cannot be pinged, so of course the TCP connection attempts from HB fail.
Just wondering if anyone elses does similar, or maybe I should be contacting Rinnai because mine is dodgy ?
@groutley, it sounds dodgy to me. I haven’t experienced that type of behaviour with my Rinnai Touch WiFi module.
Mine is installed in the roof cavity and is about 3 - 4 meters from the router (located in a cupboard)
@groutley - Maybe try a new power supply? I’ve seen occasions when a PSU goes faulty and causes dropouts when the unit drawing power can’t get enough and so resets itself due to low voltage conditions? Not saying it IS the cause, but … maybe?
Hey @Mantorok - I’m just looking at this reconnection issue I might have. Per your previous comment about topics only being published only if there has been a change - So is the debug line entry ConnectionFormat publish not actually doing an MQTT topic publish? My observation is that these lines get created during the PublishFrequency of every 60secs, however per the screenshot below, the listening broker doesn’t receive anything. Is this by design?
If I listen to all (#) the topics from all devices/sensors, etc, it looks like they all send status updates regardless of change, which would keep states in sync. I’m not sure if this is an industry best practice, but it might make sense to do this for the plug if it’s not going to add load. Others may have thoughts on this?
That is correct. The plugin keeps a cache of all the states it has published for each topic. When it’s about to publish to MQTT (say after the 60 sec interval) it compares the current state to the one in the cache and if they’re same it won’t publish. This occurs even when a connection fails, it just carries on once the connection is eventually restored.
Would you prefer it clear the cache after a connection failure so all topics will be published once the connection is restored?
But if you’re not keeping a constant connection (like I am) then wouldn’t it then re-publish EVERY time it reconnects, even for legitimate connections? Or would it only publish after seeing “TCP Connection: Failed” ??
I’ve been searching for some MQTT standards without luck. I’ve got a heap of devices with Tasmota firmware loaded on them and have observed they all republish their states for all topics every 8secs.
