Thanks for the feedback @mitchmario and thank you for your help and input too. Glad to hear it’s working for you and with Google Home as I wasn’t able to test that it would work with it.
Can you now assign the thermostats to different rooms?
Also, did it just work “out of the box” or did you need to add the platform to the config.json file and tweak some things?
Yep I can assign my two thermostats to different rooms. The status makes sense now - ‘Downstairs is 18C heating to 22C. Upstairs is 20C heating to 22C’
It worked out of the box for me. I just added “showAdvanceSwitch”: false as I don’t use programs on my NC-6.
The only thing that I can imagine improving is the response times, but I imagine it’s the Brivis Wifi Module that’s the bottleneck. I wish instead of polling each time it supported a constant connection. I’ve noticed my Home Assistant switches and sensors update instantly in Homekit. Does Home Assistant have any advantage over Homebridge with their Homekit implementation?
I went for stability over speed so tried to keep the TCP connection open as short as possible which means it does open/close connections a lot. It also waits 0.5 sec between sending commands and 1.1 secs after closing the connection before attempting to open it again. If I didn’t do this I found the module stopped responding altogether.
I know next to nothing about HA so not sure why it would be more responsive than Homebridge. I’m finding Homebridge is updating my Home app quicker in ver 2.0 than 1.x. Do you install my plugin in both HA and Homebridge at your place, so there are 2 instances running?
The “Advance Period” switch was a last minute addition for my own benefit but wasn’t sure how useful it would be to others so I provided that config option to turn it off. What I should do it hide the switch when it’s in “Manual” mode.
BTW, as you have 2 controllers do you have 2 seperate programmes? eg. You could set one programme for upstairs and a different one for downstairs? My plugin doesn’t support that. Perhaps a future enhancement.
Yep that makes total sense, and it’s faster than the Brivis App anyway so thats great. I have found while I was messing around with it, turning the heater and cooler on/off in quick succession, that the module would stop responding and I’d have to restart it. But I haven’t found that to happen with normal use.
Actually comparing the speed of Home Assistant to Homebridge probably wasn’t fair as I just have a single switch in HASS. But I do notice there is never any ‘updating’ in the Home app for the switch, it’s just always ready to go. Where as my Homebridge devices would always take a second of ‘updating’ to be ready. I think I need further testing on this one.
I only have one instance of your plugin running, I’m not sure how I would run it in Home Assistant?
I tried to set a programme on my NC-6 but it’s too old and un-intuitive for it be useful. I’m not sure if multi-zone programmes are possible.
I realised my family and I only ever turn the heater or cooler on or off so I just set the temperatures once and made these scenes. Works great!
I have some other Homebridge plugins and they also show “Updating…” for a second or two so it’s probably a Homebridge thing. When my phone is on 4G it takes even longer.
I know what you mean about the NC-6 being non-intuitive. I used to have one too before upgrading to the Touch. We tend to use the programme for heating as living in Melbourne it’s on for 9 months of the year. For cooling we don’t really use the programme and like you just have it on manual and switch on/off as needed.
Looking at the sample status you posted it appears as if it might be possible to have individual programmes for each zone. Each zone has it’s own period (Wake, Leave etc) and the option to advance to the next one.
Are you able to set the temperature for one zone from the controller of the other zone? eg. Set the Upstairs temp from the downstairs controller. If so I suspect you can also adjust the programme of the other zone too.
Awesome work guys! I’ve been trying to get this up and running in HA for while, and now I’m one step closer.
I loaded up a HomeBridge docker container on Hassio (using this guide: https://community.home-assistant.io/t/tutorial-add-homebridge-to-hass-io-using-portainer/140423/4) and installed your plugin, which automatically found my Rinnai Touch, with 3 zones+fan+advperiod. It works perfectly in Homebridge, and Apple devices. There’s only a minor delay, and the only suggestion I have is automatically turning the circulation fan off when the heater/cooler is turned on, and vice versa. Looks like you need to turn the active one off first.
Now when HA automatically detects the new HomeBridge device and you select configure, it pulls the thermostat device in okay and works, however it has trouble importing the fan and zones.
Logs from HA below. Any suggestions??
David
2020-04-13 19:26:32 ERROR (MainThread) [homeassistant.components.switch] Entity id already exists - ignoring: switch.zoneswitch_a. Platform homekit_controller does not generate unique IDs
2020-04-13 19:26:32 ERROR (MainThread) [homeassistant.components.switch] Entity id already exists - ignoring: switch.zoneswitch_a. Platform homekit_controller does not generate unique IDs
2020-04-13 19:26:32 ERROR (MainThread) [homeassistant.components.switch] Entity id already exists - ignoring: switch.zoneswitch_a. Platform homekit_controller does not generate unique IDs
2020-04-13 19:26:32 ERROR (MainThread) [homeassistant.components.fan] Error while setting up homekit_controller platform for fan
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 186, in _async_setup_platform
await asyncio.gather(*pending)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 295, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 447, in _async_add_entity
await entity.async_update_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 284, in async_update_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 327, in _async_write_ha_state
attr.update(self.state_attributes or {})
File "/usr/src/homeassistant/homeassistant/components/fan/__init__.py", line 181, in state_attributes
if not hasattr(self, prop):
File "/usr/src/homeassistant/homeassistant/components/homekit_controller/fan.py", line 91, in current_direction
return HK_DIRECTION_TO_HA[direction]
KeyError: None
2020-04-13 19:26:33 ERROR (MainThread) [homeassistant.util.logging] Exception in async_write_ha_state when dispatching 'homekit_controller_0E:A4:6A:A9:B2:0A_state_updated': ()
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 297, in async_write_ha_state
self._async_write_ha_state() # type: ignore
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 327, in _async_write_ha_state
attr.update(self.state_attributes or {})
File "/usr/src/homeassistant/homeassistant/components/fan/__init__.py", line 181, in state_attributes
if not hasattr(self, prop):
File "/usr/src/homeassistant/homeassistant/components/homekit_controller/fan.py", line 91, in current_direction
return HK_DIRECTION_TO_HA[direction]
KeyError: None
Thanks @David_M, it should be easy enough to add your suggestion to turn off the heater/cooler when turning on the fan and vice versa.
Not sure about those HA errors. It looks like the 3 zone switches are all named zoneswitch_a but I’m not sure where it’s getting those names from. The plugin names the accessories as "ZoneSwitch A", "ZoneSwitch B", ... and the switch services are named "Zone A", "Zone B", ... unless you’ve assigned them names in the Touch Controller (if you have this type of controller).
As for the fan error it looks like HA is expecting the fan rotation direction to be defined which the plugin doesn’t do as it’s an optional characteristic of the Fan service. I could try hard coding a value to see if that helps.
Are you able to post samples of your module’s status when the unit is OFF and ON (both heating & cooling). It might provide some clues as to what is going on.
Hey @Mantorok,
HA automatically replaces all spaces and capitals when it creates its own entities, so that is why we see zoneswitch_a.
On a closer look, it looks like it tries to create a ‘Fan’ device, with three associated sub-entities.
‘Thermostat A’ sub-entity, which does appear to work for controlling Heat/Cool/TempSet.
‘ZoneSwitch A’ sub-entity, which also appears to toggle Zone A on/off.
‘fan.fan’ sub-entity, which is a corrupt object, which is generating the continous exception in the logs.
The HA status screenshots are below. Thanks in advance.
David
Could it be because the manufacturer and model are the same for each accessory in Homebridge so HA is trying to create a single device with multiple sub entities rather than multiple devices?
Either the manufacter or model must be coming from the docker container hostname, which I had to set to be the same as the hass.io hostname (homessistant), as I was getting an error using anything different. I’ll try setting it to be something different and troubleshoot the container error and see if it populates the manufacturer or model differently.
Cheers,
David
The plugin populates the manufacturer and model with hardcoded values (ie. Rinnai & N-BW2) for all the accessories. I could change it so that the model is unique for each accessory if you think it will help. Maybe it will then create a HA device for each of the plugin’s accessories rather than trying to group them all under the one device
Have you tried removing the fan by setting showFan to false in config.json? Just to see if the fan is the cause of the error
So it looks like there are two issues. I set the showFlag flag to false, which stopped the HA error related to HK_DIRECTION_TO_HA - So maybe if you could hard code a value we can test that out.
The integration still only imports the controller and one accessory which is now the AdvanceSwitch. However, it looks like it is a known issue with HomeBridge:
Platform homekit_controller does not generate unique IDs
According to this, each accessory needs to have a unique serial number.
Cheers,
David
@Mantorok - I updated my local index.js to generate a random serial number as per the following:
.setCharacteristic(Characteristic.SerialNumber, Math.ceil(Math.random() * 10000));
After doing this, all the accessories successfully get imported in to Home Assistant. The fan is still busted, so I tracked down the fan.py the error references
# 0 is clockwise, 1 is counter-clockwise. The match to forward and reverse is so that
# its consistent with homeassistant.components.homekit.
DIRECTION_TO_HK = {
DIRECTION_REVERSE: 1,
DIRECTION_FORWARD: 0,
I tried seeing where we could force the value in your code, but that was beyond my skills…
There does also seem to be something odd going on with the zone status refresh in HomeBridge. Zone A is always Off when HomeBridge is reset. And Zone A/B/C seem to change their last setting when switching between Heat/Cool/Fan. I’ll keep an eye on this. There might be some sticky config somewhere.
Cheers,
David
Great work David. I’ll change the plugin so it will generate a unique serial number for each accessory. I thought the fan issue may have something to do with the direction so I’ve already made a change to set a value for it.
I’m not sure what could be causing the Zone A switch always being off after resetting homebridge. Does this happen for iOS devices as well as Android?
You could try turning debugging on and look at the logs to see what the status is reporting for Zone A.
I’ve just released a new version of the plugin which should (hopefully) help with some of the HA issues mentioned above. It also adds some stability improvements when sending commands to the WiFi module.
@David_M, please let me know how it goes.
Fantastic! From my intial testing, I can confirm that a) Fan accessory is imported successfully, and b) Toggling between Heating/Cooling and the Fan is successful.
@Mantorok - Thanks for your help with this. It’s not a direct HA integration, but it seems to work quite reliably. There is a entity sync delay in HA when toggling the accessories with HomeBridge (sometime up to 30secs), but from what I’ve found, it looks like it might be a common issue. Seems to work perfectly within the HomeBridge portal itself.
From what I understand the Rinnai Touch publishes the current temperature to the wi-fi controller, but becaue I’m using a Networker NC6, the temperature remains 0c. Is this right?? If so, it’s not ideal,but its only informational and I can get this info from a separate sensor…
Cheers,
David
That’s great news, glad it’s working better now
As for the NC6, does the controller itself show the current temperature on its display? If so it should be in the status that is output by the wifi module. I believe @mitchmario also has this controller (2 in fact) and it shows the temperature for him
Check a sample of your module’s status json blob to see if it’s in there. It’s usually the value associated with key “MT” (value is 3 digits). You may just need to enter a mapping override in the config.json file to fix it
Thanks, @Mantorok.
Unfortunately the mobile app doesn’t show the current temperature either. I’ve just checked the MT value and it is always 999. No other values look like they represent what’s displayed on the LCD (22c).
('[{"SYST": {"CFG": {"MTSP": "N", "NC": "00", "DF": "N", "TU": "C", "CF": "1", "VR": "0183",
"CV": "0010", "CC": "043", "ZA": " ", "ZB": " ", "ZC": "
", "ZD": " " }, "AVM": {"HG": "Y", "EC": "N", "CG": "Y", "RA": "N",
"RH": "N", "RC": "N" }, "OSS": {"DY": "SAT", "TM": "23:35", "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": "Y", "ZDIS": "N", "CF":
"N", "PS": "Y", "DG": "W" }, "OOP": {"ST": "N", "CF": "N", "FL": "00", "SN": "N" }, "GSO":
{"OP": "M", "SP": "20", "AO": "N" }, "GSS": {"HC": "N", "FS": "N", "GV": "N", "PH": "N",
"AT": "W", "AZ": "W" }, "APS": {"AV": "N" }, "ZUO": {"UE": "N" }, "ZAO": {"UE": "Y" }, "ZBO":
{"UE": "Y" }, "ZCO": {"UE": "Y" }, "ZDO": {"UE": "N" }, "ZUS": {"AE": "N", "MT": "999" },
"ZAS": {"AE": "N", "MT": "999" }, "ZBS": {"AE": "N", "MT": "999" }, "ZCS": {"AE": "N", "MT":
"999" }, "ZDS": {"AE": "N", "MT": "999" } } }]',options)
Oh ok. If it doesn’t show in the mobile app then the plugin won’t be able to display it either. The plugin will look for an MT value 999 and return null which Homebridge interprets as 0.0c. You could try contacting your supplier or Brivis/Rinnai and ask why the current temp is not showing in the mobile app. It could just be service config option on the controller or something.
An enhancement I’d like to add to the plugin is to sync the time on the controller with the host machine the plugin is running on. I find the internal clock on my controller is fast so I’m always adjusting it to the correct time.
There was mention by @FrontBottom in an earlier post of an STM command for setting the day/time which I’ve tried to get to work but with no luck yet.
@mitchmario posted instructions (see post #36) on how to disassemble the Android APK file but its for Windows and I use a Mac. Does anyone still have a copy of the code that relates to the STM command that they can post somewhere?