@Mantorok Thank you for this ever-improving plugin!
I was just updated the plugin to 3.3.1 and then updated homebridge to 1.3.0
and noticed as it started up…
[2/22/2021, 11:02:39 AM] [Rinnai Touch] Controllers found: 1
[2/22/2021, 11:02:39 AM] [Rinnai Touch] Common
[2/22/2021, 11:02:39 AM] [Rinnai Touch] Gas Heater found. Zones: 1
[2/22/2021, 11:02:39 AM] [Rinnai Touch] Common
[2/22/2021, 11:02:39 AM] [Rinnai Touch] Evaporative Cooler found. Zones: 2
[2/22/2021, 11:02:39 AM] [Rinnai Touch] Common
[2/22/2021, 11:02:39 AM] [Rinnai Touch] Zone A
As the plugin Autosenses what I have…
Now it’s close, but not 100% accurate…
The above says I have 2 zones on my cooling and 1 on the heating…
But its the other way around!
Is there a way to over ride that, or improve the autosensing so tha Zone A is on my heating, not the cooling ?
Version 3.3.2 of the plugin has been released. This release has the following changes:
[FIX] HeaterCooler intermittently turning on and setting to AUTO mode
[FIX] Incorrect zones found during auto-discovery
Cache discovered HVAC configuration for faster startup
Improve support for Child Bridges (in Homebridge 1.3.x)
@groutley, I’m hoping this release will solve your zone issue. I think the module doesn’t correctly report the zones when the HVAC is off so I’ve changed the auto-discovery to turn it on while it scans for the zones. The downside of this is that it takes longer to do the scan, however, the plugin will now cache the results of the scan so subsequent restarts of homebridge will be quicker.
If this doesn’t solve your problem there is now also a work-around. You can edit the cache file and change the zones in there. The file is named RinnaiTouchPlatform.json and is located in the Homebridge storage path.
Please let me know how it goes.
EDIT: Forgot to mention you can force the plugin to perform an auto-discovery via a new setting aptly named “Force Auto-Discovery”. This could be useful if your HVAC config changes
Sorry all, I just realised there’s a bug in the new version so you may want to hold off upgrading for now. I’ll get a new version out soon.
If you have upgraded don’t worry it’s just an error that occurs when the new cache file does not exist which will happen once you restart homebridge after upgrading. The plugin will create it but you’ll need to restart homebridge once more before it will take effect.
UPDATE: Version 3.3.3 of the plugin has been released which fixes the above mentioned bug.
UPDATE 2: Version 3.3.4 of the plugin has been released. This fixes an issue with pushover notifications that can cause the plugin to crash when the internet connection is down.
During the past few days, I have read all 604 posts in this thread - multiple times! What an amazing community! I was able to find all the information I was looking for, to integrate my Brivis system with Home Assistant!
I have a gas ducted heater with add-on refrigerated cooling. Two zones. Two NC-6 networkers - one in each zone. I’m running HA on a RaspberryPi 3B+. I was able to install Portainer, then Homebridge, and @Mantorok’s plugin which works flawlessly - you sir, are an absolute legend! Thank you!!
I’ve also installed The MQTT integration get the thermostat entity working, and also have the script to publish zone temperatures of two Z-Wave Aeotec MultiSensors placed near the thermostats. Works great!
There are so many members who have posted on this thread who should be thanked, so in case I miss anyone, THANK YOU ALL - thanks for the YAML, thanks for the UI inspiration and the countless questions and bug reports that made my integration experience a breeze!
Hey @Mantorok - thank you again for your great work on this plugin.
After months of rock solid performance, I have upgrade a bunch of things (including your plugin to the latest version) and am now starting to see issues.
The first thing that I noticed (and may be the simplest one) - is that the plugin correctly detects my Brivis system and Rinnai module upon initial install and auto discovery. The below screenshot illustrates a normal working scenario. I can control the HVAC system and everything is fine.
However - when I reboot Homebridge - the system reverts to the below (incorrect status) and I am unable to control HVAC via Homebridge. A simple task such as changing the temp in HB results in an error in the logs - “unable to change setpoint in Zone D due to module’s current status”.
The only way to fix the problem is to tick the “Clear accessories cache on restart” option in the plugin config. Keeping that option ticked means that my system is correctly recognised and controllable after each reboot. As soon as I untick that option and reboot, I get the above issue.
Hi @infocus13, sorry to hear the plugin is not working quite right for you. It sounds like you have a Multi Set Point system (ie. multiple controllers) which I don’t have so its difficult for me to test.
Could you please supply a copy of your config as well as the contents of the RinnaiTouchPlatform.json file.
One thing you could try is setting the new forceAutoDiscovery to true instead of clearing the accessory cache. After restarting Homebridge it will do a full scan of your system so it may resolve the issue for now. Let me know how it goes
Hey @Mantorok - yes I do have a MSP. My config is as follows:
Brivis ducted heating + refrigerated aircon
4 independent zones
Zones controlled by 2 x NC-6 Networkers
Rinnai WiFi module
Setting Auto Discovery to true and unselecting Clear Cache results in the following view after a reboot - obviously incorrect and uncontrollable through HB.
The Rinnai config file consists of only 1 line (is this correct?) note this is the file after the “Force Auto Discovery” option is turned on. It states a “U” controller which I assume is a common zone/single set point, which is incorrect?
Yes the file is quite small. Looks like it’s not writing the correct setup for MSP. As a workaround can you edit the file and replace “U” with the same as the heat and cool values (ie “A”, “B” etc). Then restart. You may need to clear the cache too but try without doing that first
You’re right that the controllers are now being populated correctly.
So should I manually edit the file and then reboot? Wouldn’t that cause the same issue? I.e. the file is “correct” now so there’s nothing really to edit. If I was to reboot, I will end up with the original problem…
Scenario 2 - starting with the “known good” config from Scenario 1, untick “Clear Cache” and reboot - plugin detects the zones and their ambient temperatures correctly but set points are incorrect and system is not controllable from HB
Note that JSON file is the same in both scenarios so it cannot be that. Also the plugin is picking up the right zones in Scenario 2 and is picking up the right ambient temps - just the set point and ability to control is missing.
Playing with a few more combinations of various scenarios, clearing various caches, reinstalling the plugin (even older versions) and the only thing that results in a working system is have the “Clear Cache” option ticked.
Hey mate, thanks for looking into this. I’m going to park this issue for now.
My HVAC system started behaving very strangely after the addition of extra zones last week. Random reboots, overshooting the set point temp, etc. Had the installers come out again today and they reckon the main controller board is cactus. Apparently Brivis had issues with controllers installed before middle of last year. The board starts to fail and causes random issues.
Brivis will be doing a controller replacement next week. I am hoping that will fix the issue. Your plugin was working flawlessly for 9 months and issues only appeared after the HVAC reconfig last week, which is when the controller started to fail.
No worries. That may explain why the JSON file contained “U” for the controllers at one point as the status coming back from the WiFi module wasn’t properly representing your HVAC’s setup. That file is only written once unless the “Force Auto Discovery” is turned on. Even clearing the accessory cache won’t touch that file.
So Brivis replace the controller board and the HVAC system is now behaving as expected. No more random hourly restarts, overshooting the setpoint, etc.
However I still have the same issue with the plugin in that having the “clear accessory cache” option ticked is the only thing that results in a usable Homebridge (and therefore HA) controller. Unticking that option brings back a HVAC view I showed above - all setpoints at 8 degrees and unable to control.
When tailing the HB logs when changing the setpoint in this “error” state I get error messages like “unable to change setpoint due to current controller state” or something similar. I can recreate and provide the exact logs if that helps.
Is there any further troubleshooting I can do? I guess having the clear cache option permanently ticked isn’t a big deal but I’m curious on why it’s behaving like this!
To help diagnose the problem can you show me the logs from when homebridge is retarted, both with and without the “Clear accessory cache” option checked.
Can you also provide the module’s status when the HVAC is in the following states:
Off and in Heating mode
On and in Heating mode
Off and in Cooling mode
On and in Cooling mode
To get the module’s status you’ll need to check the “Show Rinnai Touch Module status in the log” option in the settings.
That should provide me with a clearer picture on how the plugin behaves with your particular setup.
This isn’t necessirily a Homebridge integration query but more of an issue I’m having with the Wi-Fi module. I have the module under the house near the Brivis HX30 unit. The wifi module gets dusty and the power button is already starting to stick. I want to move it in to the garage.
I have run a new 0.75mm wire to the garage which is about 10mtrs. when all is powered off, I relocate the wifi module and connect the wire terminals, and then disconnect the old wire and connect the new one in parallel with the other thermostats.
I have two NC-6’s, a master and slave. When the units are powered back on, everything seems okay. The thermostats operate normally, but as soon as the first poll/signal is sent from the wifi module, the NC-6’s go blank. Not dead, as the time is still displayed, and blue backlight still works. The only way to get it back online is to power cycle the Brivis unit.
The only difference is the length of the cable. The shorter cable is 0.75mm flex, and the new one is 0.75mm speaker cable, however the master is using the same type of cable. It’s really perplexing. I think it might be something to do with the installer parameters. I have tried many combinations of different cables and checked the voltage and current is the same with a multimeter.
If anyone has seen something similar with a solution, please let me know.
The latest release fix both my issues with the plugin - the “clear cache” bug and also the fact that with the previous version I was unable to restart your plugin without having to reboot HA. The connectivity seemed to be lost/error out on HB reboot, which made for a very painful/long troubleshooting process.
