Thanks for doing this @Sabellwind. I too have Evap and hadn’t got around to articulating some of the wierdness. I personally always run Evap in manual - and as you have noted, the plugin keeps setting it back into comfort mode. I’d be keen for a control to effectively lock it into manual mode, and then on/off that.
Hi @FrontBottom
No worries. If your setup is anything like mine, you should be able to make manual mode stay in manual mode by just doing
- service: switch.turn_on
entity_id: switch.manual_mode #or whatever you've named your manual mode switch
My setup isn’t exiting manual mode on it’s own. What I’ve observed, is that it switches from manual mode when I either:
- Turn the manual mode off
- service: switch.turn_off
entity_id: switch.manual_mode #or whatever you've named your manual mode switch
- Change the thermostat value from HA.
If you’d want to turn the evap cooler off from manual mode, all you’d need to do is
- service: climate.turn_off
entity_id: climate.heater_cooler #or whatever you named your climate entity
I also fixed a lot of my weirdness in my Homekit Controller integration by setting the plugin to be in Thermostat mode, not Heater Cooler:
Hi @FrontBottom,
From homebridge’s thermostat accessory, the Rinnai’s AUTO mode should only be set if you select AUTO mode or you set a temperature (as it assumes you want to set a Comfort level)
However, there may be a possible bug that could switch the Rinnai to AUTO mode if Homebridge triggers a “set TargetTemperature” event even though the temperature hasn’t changed. It’s hard for me to test for this scenario since I don’t have an Evap. You may see this in the Homebridge logs though.
To avoid this I can make a change to the plugin that ignores the TargetTemperature setting if it’s in MANUAL mode rather than changing to AUTO mode. Again I could make this a setting so you turn it on or off. What do you think?
Howdy - that might do it. I should probably capture some logs to better undertsand what it is doing (and fully understand it is a bit difficult for you to dev blind for the Evap case!)
Version 3.2.2 of the plugin has been released. This version includes new settings for Evaporative Coolers:
- New “Invert Comfort Level” setting. When set to true, increasing the temperature on the thermostat accessory will decrease the comfort level on the Rinnai/Brivis controller, and vice versa.
- New “Set AUTO operating state” setting. When set to true, changing the temperature on the thermostat accessory will set the operating state of the controller to AUTO (if currently MANUAL). If set to false and the controller is in the MANUAL state then setting the temperature on the thermostat will have no effect
NOTE: These settings have no effect on heaters and Add-On coolers
@FrontBottom, @Sabellwind could you please let me know if this update fixes your issues or if you’re still getting some weird behaviour.
1 Like
Hi mate, that fixed it! The thermostat now adjusts the comfort level properly, and this makes my wrappers which inverted the value redundant! Thanks so much for the quick turnaround.
1 Like
I’m confident it’ll fix it too - will report back after the coming heatwave 
Merry Christmas everyone!
I’ve just released version 3.2.3 of the plugin. No new functionality, just updated the dependent packages, one of which had a low severity vulnerability.
1 Like
@Mantorok Merry Christmas!
Thanks for all your work on the plugin.
I’ve recently revamped Floorplan for Home Assistant, and I’m working on putting together a simple example to demonstrate your plugin. Great job by @David_M for using Floorplan in his setup.
At the moment, I’m using a HA input_select as a drop-down type of mechanism to allow for selecting the fan speed. I have an automation set up that keeps the drop-down in sync with the fan speed published from your plugin.
Here is the drop-down list that allows for selecting a fan speed:
input_select:
hvac_fan_speed:
name: HVAC Fan Speed
options:
- 'low'
- 'medium'
- 'high'
Below is the automation that calls your plugin when an option is selcted in the drop-down.
- alias: On HVAC Fan Speed input change
trigger:
platform: state
entity_id: input_select.hvac_fan_speed
action:
- service: mqtt.publish
data:
topic: rinnai/hvac/fan_mode/set
payload: "{{ states('input_select.hvac_fan_speed') }}"
Below is the automation used to automatically select the drop-down option based on the current state published by your plugin.
automation:
- alias: On HVAC Fan Speed change
trigger:
platform: mqtt
topic: rinnai/hvac/fan_mode/get
action:
- service: input_select.select_option
data:
entity_id: input_select.hvac_fan_speed
option: "{{ trigger.payload }}"
The issue with this current solution is that it could take a while for drop-down to reflect the real state of the plugin, when an ‘invalid’ option is chosen. In other words, when selecting an option in the drop-down, if that option is invalid (as reported by the plugin), the selected option will remain ‘selected’, until the next publish interval, which is when the automation will reset the drop-down back to the current ‘valid’ state, as reported by your plugin.
I wonder whether it would make sense to add another option to the plugin, which would allow for republishing the current state of the Rinnai, whenever a warning (i.e. MQTT: Setting fan mode only supported for "fan_only" mode) is generated.
By doing that, my drop-down would then ‘immediately’ be able to revert back the state is was originally in, that is, the current state as per the plugin.
BTW, another alternative might be to introduce a new MQTT command that allows the client (i.e. HA) to requests for your plugin to publish the current state, in an ad-hoc manner.
Hope this all makes sense, and that I’m approaching this the ‘right’ way.
Thanks!
Petar
Hi @pkozul,
Either of those options is fine with me, so whichever one suits you best.
Another option could be that setting the fan mode (ie. speed) will automatically switch the HVAC into fan_only mode if it’s not currently in that mode.
Just let me know.
Regards,
Mantorok
@Mantorok I think the cleanest way would be for the plugin to return the current state when it encounters a warning / error scenario. In a logical sense, it would ‘reply’ back to the client, letting the client know that the requested command did not succeed, and therefore did not change the state of the unit.
I guess this is due to the nature of HA input_select which acts in an ‘optimistic’ sort of mode. The only way to ‘correct’ it, is for the plugin to send it the current state.
Thanks!
Petar
Hi @pkozul,
I’ve released version 3.2.4 of the plugin. The plugin should now republish all topics when a warning occurs (ie. a command is unable to be performed).
Regards,
Mantorok
Hi guys. I’m revisiting this thread from a while ago. I have a brivis central heating unit and I am considering purchasing the wifi gateway to connect this into my network.
I can see and understand the nodejs plug-in for homebridge as discussed above, but I’m a little confused with the integration back into home assistant.
If I proceed to install homebridge and integrate that back into HA, doesn’t this mean I need to disable the HA native integration for HomeKit? Homebridge to HA integration was discontinued some time ago as the native plugin matured.
I totally understand this is to enable accessory use and not for HA HomeKit integration, however is there a conflict somewhere here?
Or are we installing homebridge side-by-side and some plug-in/add-on is used to communicate from HA to a web service/api on homebridge without actually enabling homebridge within HA?
I tried hard to read through this thread but it was unclear what the “recommended install” procedure was meant to be.
Many thanks,
Cheers, Wiz!!
Edit: I’ve just seen the MQTT notes on the NPM page. So we are going to install homebridge and homebridge-rinnai-touch-platform somewhere and then use MQTT references in HA to communicate - is this correct?
I’m actually using both the HA/HomeBridge interface as well as MQTT control (in Node-Red) to control mine. Works like a dream.
Getting the WiFi interface for my Rinnai the best thing I’ve added to HASS!
Hi @Mantorok Was on holidays and got stuck in NSW. Just got back to VIC. Thanks a lot for the enhancement!
1 Like
Hi @Mantorok
I’ve been following this post for a long time now! Thanks for your efforts. I’ve finally configured homebridge and got your plugin working.
Just FYI for anyone else having any issues, I kept getting ‘ehostunreach’ errors when homebridge tried to connect to the Rinnai wifi controller. I tried kicking the wifi connection, restarting the rinnai controller, restarting the Access point - still no luck. Eventually I found it was connected to an AP further away, I restarted the actual access point this time and the plugin worked nearly instantly.
Cheers!
Hi @Elijah_Solly, great to hear that its working for you and thanks for the donation.
That’s a good tip for when you have multiple APs. I’ll add that to the troubleshooting section of the README.
Regards,
@Mantorok
@Mantorok I’ve been using this plugin for couple of months now through homebridge via HA. It was quite a handy tool this summer (I am in the southern hemisphere) with flexibility of all types of automation I could do to keep the temperature indoors under control.
Awesome work, mate. Thank you for the brilliant plugin and effort you put into this.
Cheers!
2 Likes
Hi all, I’ve just released a new version of the plugin. This is quite a big change so you may want to treat it like a beta. Anyone with Evap Cooling or a Multi Set Point system could you please give me some feedback as I can only do limited testing for these. If anything is broken please let me know. Here’s the main changes:
- Major code refactor to resolve commands at send time rather than request time
- Deprecate ‘Native’ MQTT format
- [FIX] Push notifications not being sent for TCP/IP connection errors
- New device discovery
- Add “Seperate Mode Accessories” setting
- Add “Seperate Fan Zone Switches” setting
- AUTO mode in Thermostat/HeaterCooler accessory sets temperature range
The plugin will now do a deeper scan of your HVAC during startup to determine the zones for both heating and cooling in case there’s a difference. This is quite likely if you have heating and evap cooling.
Apologies if anyone used the “Native” MQTT format but it was becoming difficult to maintain. If anyone does still want it please let me know and I’ll see what I can do.
The 2 new “Seperate …” settings will allow for more granular control of the HVAC. I found that it was difficult to use some of the accessories in HomeKit Scenes and Automations so this should help with that.
The new AUTO mode is a bit of an experimental feature that allows you to set a temperature range. The plugin will attempt to keep the current temperature within the specified temperatures by automatically switching between heating and cooling modes when necessary. See the “Notes about AUTO mode” in the README for more details.
Please post any questions or feedback.
Enjoy,
@Mantorok
1 Like
I’ve released a new version (3.3.1) of the plugin which fixes a minor issue that occurs in Homebridge version 1.3.0. When Homebridge attempts to get the target temperature when the HVAC is off it was returning zero which is outside the allowed temperature range (8 - 30) and was raising a warning in the log.