hey @rgoodworth.home - They might be adjustable. I’ve got the Zone Plus dampers, which have a red hat on them, plus I’ve got a manual dampener with a lever to adjust the airflow in the main bedroom, as the airflow is greater than the rest of the house. If you can get access to the ducts with your phone, maybe turn the zone on/off and hear/feel if the small motor is cranking over.
Great idea, i’ll try that. THANKS David.
Hey David… So interestingly I’ve upgraded HA to the latest release (0.113.4) and the plugin has been rock solid ever since on default settings.
The nightly timeouts were happening before on 0.110.x.
Thanks @Mantorok for your amazing work.
Have just ordered the Brivis WiFi interface from e-bay…
Looking massively forward to integrating this with my HASS set-up!
Unfortunately I can’t deploy HomeBridge on my HASS-Pi due to issues with Portainer 1.2.1 
Hopefully they fix that by the time my unit arrives on my doorstep!
Hey @Mantorok - I’m just curious about this error below I’ve received a few times. But it only happens after I’ve had to power cycle the wifi module. It’s like it can’t recover from the disconnection. The connection status remains as ‘ok’ also.
Restarting HomeBridge resolves it.
[8/16/2020, 1:39:53 PM] Homebridge is running on port 51809.
[8/16/2020, 1:39:53 PM] [RinnaiTouchPlatform] Found: Rinnai Touch module [192.168.1.146:27847]
[8/16/2020, 1:39:53 PM] [RinnaiTouchPlatform] TCP Connection: Open
[8/16/2020, 1:39:55 PM] [RinnaiTouchPlatform] TypeError: Cannot convert undefined or null to object
at Function.keys (<anonymous>)
at StateService.getState (/homebridge/node_modules/homebridge-rinnai-touch-platform/src/services/StateService.ts:69:33)
at RinnaiTouchService.init (/homebridge/node_modules/homebridge-rinnai-touch-platform/src/services/RinnaiTouchService.ts:53:48)
at runNextTicks (internal/process/task_queues.js:62:5)
at processImmediate (internal/timers.js:429:9)
at RinnaiTouchPlatform.discoverDevices (/homebridge/node_modules/homebridge-rinnai-touch-platform/src/platform.ts:58:7)
Just an FYI for anyone trying to install HomeBridge via Portainer on their HassOS at the moment and getting the dreaded “Object not found in database” error…
There is a bug, they’re aware of it and as they’ve been aware of it for 18 days now…hopefully a patch release should be coming out soon?!
Times like this I wish this Rinnai module was a ‘native’ HassOS addon 
@Mantorok …?
@Mantorok
As @Rusti-gotrage said … is there any hope Rinnai module will become HassOS addon??? Pretty please??? 
Only if someone develops one! @Mantorok doesn’t even use HA, so it is unlikely to come from him! (Having it in HomeBridge has actually worked well in my case, as it makes it easy for other family members to control the settings via their iOS devices)
Hi @David_M. That issue looks like the module may be emitting an unexpected response. Could you enable homebridge debug mode and capture the log for when you restart the module. It’s difficult for me as my module is located in the roof cavity
As for those that maybe hoping I could develop a HA addon it’s unlikely I would in the short term. As @FrontBottom mentioned I don’t use HA myself. Maybe one day if I start using it
1 Like
I was FAIRLY certain that was the case - I was mostly asking in jest (and out of Frustration at this Portainer screw-up! ) But I’ve got my Rinnai WiFi module in the mail today - should be here in about 4-8 business days (maybe less?)…
So I’m REALLY hoping that the Portainer issue is resolved by then so I can get HB and HA talking!!
Your module looks EXCELLENT…and I can’t wait to be able to actually USE it… 
@Mantorok - I tried to replicate the error, but in the process killed my thermostat a couple of times after cycling the wifi module. The networker screen goes blank and the only way to get it on again is to go outside and power cycle the heater and zone plus. I think I might have some wiring issues, as the installer has wired the 2x thermostats and wifi module in parallel, not in series (daisy chained). He also used the original analogue speaker wire on the main thermostat. So I’m thinking if there is any irregularities in the 16v the thermostat drawers, then it just shuts it down. If any installers comes across this thread, let me know if they should be rewired in series or just to ditch the speaker wire for figure 8 flex.
Anyway, I got the same error in the HB logs with debugging, but it produced no extra info, however if I refreshed (F5) on the debug screen, it does show this error which looks like it may be related.
[1597998655298] ERROR (21383 on homeassistant): Promise may not be fulfilled with 'undefined' when statusCode is not 204
reqId: 5
err: {
"type": "FastifyError",
"message": "FST_ERR_PROMISE_NOT_FULLFILLED: Promise may not be fulfilled with 'undefined' when statusCode is not 204",
"stack":
FastifyError [FST_ERR_PROMISE_NOT_FULLFILLED]: FST_ERR_PROMISE_NOT_FULLFILLED: Promise may not be fulfilled with 'undefined' when statusCode is not 204
at /usr/local/lib/node_modules/homebridge-config-ui-x/node_modules/fastify/lib/wrapThenable.js:34:30
"name": "FastifyError [FST_ERR_PROMISE_NOT_FULLFILLED]",
"code": "FST_ERR_PROMISE_NOT_FULLFILLED",
"statusCode": 500
}
Hi @David_M, unfortunately that error doesn’t help much. When Homebridge is in Debug mode you should see extra log messages which should show the JSON status. How are you setting Homebridge to Debug mode?
Here’s an example of what I see in the log at the same point as your sample above when Debug mode is on:
[8/22/2020, 12:05:47 PM] Homebridge is running on port 51826.
[8/22/2020, 12:05:47 PM] [RinnaiTouchPlatform] QueueService process { type: 0 }
[8/22/2020, 12:05:47 PM] [RinnaiTouchPlatform] QueueService connect
[8/22/2020, 12:05:47 PM] [RinnaiTouchPlatform] TcpService connect
[8/22/2020, 12:05:47 PM] [RinnaiTouchPlatform] UdpService getAddress
[8/22/2020, 12:05:47 PM] [RinnaiTouchPlatform] Found: Rinnai Touch module [192.168.1.3:27847]
[8/22/2020, 12:05:49 PM] [Config] Homebridge Config UI X v4.23.2 is listening on :: port 8080
[8/22/2020, 12:05:49 PM] [RinnaiTouchPlatform] TCP Connection: Open
[8/22/2020, 12:05:50 PM] [RinnaiTouchPlatform] QueueService dataHandler N000000[{"SYST": {"CFG": {"MTSP": "N", "NC": "00", "DF": "N", "TU": "C", "CF": "1", "VR": "0183", "CV": "0010", "CC": "043", "ZA": "Bedrooms ", "ZB": "Living Areas ", "ZC": " ", "ZD": " " }, "AVM": {"HG": "Y", "EC": "N", "CG": "Y", "RA": "N", "RH": "N", "RC": "N" }, "OSS": {"DY": "SAT", "TM": "12:11", "BP": "Y", "RG": "Y", "ST": "N", "MD": "H", "DE": "N", "DU": "N", "AT": "999", "LO": "N" }, "FLT": {"AV": "N", "C3": "000" } } },{"HGOM": {"CFG": {"ZUIS": "N", "ZAIS": "Y", "ZBIS": "Y", "ZCIS": "N", "ZDIS": "N", "CF": "N", "PS": "Y", "DG": "W" }, "OOP": {"ST": "N", "CF": "N", "FL": "02", "SN": "N" }, "GSO": {"OP": "A", "SP": "22", "AO": "N" }, "GSS": {"HC": "N", "FS": "N", "GV": "N", "PH": "N", "AT": "L", "AZ": "R" }, "APS": {"AV": "N" }, "ZUO": {"UE": "N" }, "ZAO": {"UE": "Y" }, "ZBO": {"UE": "Y" }, "ZCO": {"UE": "N" }, "ZDO": {"UE": "N" }, "ZUS": {"AE": "N", "MT": "221" }, "ZAS": {"AE": "N", "MT": "221" }, "ZBS": {"AE": "N", "MT": "221" }, "ZCS": {"AE": "N", "MT": "221" }, "ZDS": {"AE": "N", "MT": "221" } } }]
I have looked at the code where the stack trace occurs and the only way an exception could be thrown there is if the JSON status is missing the 2nd element in the array which is the HGOM/CGOM details. My guess is that while the WiFi module is starting up it doesn’t provide that 2nd element for a period of time.
I’ll make a change to the plugin to handle that scenario. Hopefully that will solve it.
Version 3.0.4 of the plugin has been released. This version handles cases where the JSON status has a missing array element which may happen when the WiFi module is restarted.
@David_M, see if this solves your problem. As I’m not able to easily test this case it’s possible the problem may persist or manifest in other ways. Let me know how it goes.
Version 3.0.5 of the plugin has been released. I felt the fix I did in 3.0.4 was a little hacky and may not work in all cases so I’ve improved it a bit (hopefully). The plugin will now wait up to 4 minutes for the module to send a valid status JSON blob before giving up.
Great! I’ve updated and will let you know of any issues. I had enabled debug=true for HomeBridge and the Rinnai Plugin. If the error happens again, I’ll troubleshoot it further.
Thanks.
IT’S HERE!!!
** Unpacks Rinnai Touch Wi-Fi kit and goes to install it now **
Good luck. Hope it all works well for you
hmm - ok… well firstly - the “manual” that comes in the box with the unit is crap…
Thankfully, the internet came to my rescue and I was able to figure out how to get the unit online and on my WAP so it now is addressable via the LAN …
FYI - I’ve connected to to a Rinnai system with 4 zone (only 3 in use) heating/cooling with the cooling being a refrigerated cooling system - all running from an NC-6 thermostat.
I’ve connected the TW1 and TW2 on the control board for the HVAC unit in parallel with the NC-6 Controller.
And I can talk to it with the App on my phone - so … Yay! The Module appears to be working as intended with the Phone app…
Homebridge logs say that it has found it.
I’ve goneinto the plugin (3.0.5) settings for the plug in and the ONLY settings it will let me use under Accessory Settings is “Thermostat” and “Switch”…
Every time I try to use other settings, it just goes NOPE and next time I go in there they’re blank.
Homebridge logs say:
[8/24/2020, 2:44:04 PM] Homebridge is running on port xxxxx.
[8/24/2020, 2:44:04 PM] [RinnaiTouchPlatform] Found: Rinnai Touch module [xxx.xxx.xxx.xxx:xxxxx]
[8/24/2020, 2:44:05 PM] [RinnaiTouchPlatform] TCP Connection: Open
But it’s not listing any accessories… Thoughts??
@Rusti-gotrage, when you say “the ONLY settings it will let me use under Accessory Settings is “Thermostat” and “Switch”…” are you saying you can’t change them from the dropdown list in “Config UI X”?
They are the defaults which most people would use anyway, although I prefer the “Heater Cooler” as the Controller Accessory type myself.
So you are not seeing anything in the logs after the “TCP Connection: Open” message? I wonder if it’s something to do with the latest change I made that checks that the status is valid before proceeding. It should timeout after 4 minutes though and you should then see a “TCP Connection: Closed” message
One option is to enable debug mode in Homebridge which will show more detailed logs including the status JSON blob from the module.