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.
Version 3.0.7 of the plugin has been released. This version adds a new MQTT config option to publish all topics even though the payload has not changed. It also fixes a bug when clearing the accessory cache.
Morning all,
Not sure if it’s the new version, but I’ve noticed my ability to communicate via MQTT fails over time. It’s like the plug in just stops accepting MQTT inputs.
Interestingly, the HomeBridge commands still work…
I’ll post up logs later in the morning…
[Edit - 8hrs later]
So I had a look in my MQTT logs - couldn’t see the HomeBridge/Rinnai connecting… checked the settings in the Plug-in and restarted HomeBridge and it re-connected… Not sure what’s going on here - will monitor and let you know of any further issues…
Maybe the plugin lost connection to the MQTT Broker. If you can supply any logs if it happens again that would be great. Also, could you post your config.json