Rinnai Heating/Cooling Wifi Module

Version 2.4.2 has been released. Changes include:

  • Add ‘retain’ option to MQTT publish
  • Improve time to detect command updates

@David_M, I changed the way detection of the command updates work so that it will check immediately after a status is received from the module rather than waiting 0.5 second and checking. I noticed a slight improvement but nothing dramatic.

1 Like

Bought one of these kits from Ample Air as suggested in this thread. Very fast delivery.

Booked a regular service call with Brivis/Rinnai for the Ducted Gas Heater (it was well overdue for regular check anyway), and the technician was happy to wire up the wifi kit (I could have done it myself, but always best to have it done by someone licensed so that there’s no possibility of insurance issues down the track). It was the first time he’d seen one, and said they had only been available for a couple of months (this is in South Australia, so maybe it’s been delayed getting here from the eastern states).

Interestingly, he told me the list price if I purchased it through Rinnai would be about $600. I initially presumed that included an installation cost, but he took down the Ample Air details so that he could buy one for his own house because he said he couldn’t get it anywhere near $300 himself from Rinnai.

He asked me to show him how to set up the Rinnai App side of things.

I plan to hook it up to Home Assistant running on an RPi3 or RPi4, with some Aqara temp sensors, a ConBee II zigbee bridge, some Kogan smart plugs with power monitoring (all converted to Tasmota with tuya-convert), and a Mirabella Genio IR blaster (also Tasmota-IR) for the Daikin split system in the extension.

I have both Ducted Gas Heating (3 zones, plus an always-on common zone) and Evap Cooling (no zoning). I’ve captured wireshark files for the initial registration and also can capture traces from the Rinnai app if any of the developers here need any info that might be specific to my setup.

– Rod

@Mantorok. Good news the publishing with retain option makes MQTT more robust. Unfortunately the command detection had a negative effect for me. The logged commands seem to be quicker, but the status update takes up to 10 secs.

@David_M, are you able to provide some logs (without debug at this stage)

EDIT: Also can you post your MQTT config

No worries. Here’s the config:

"platform": "RinnaiTouchPlatform",
"name": "Rinnai Touch",
"controllers": 1,
"debug": false,
"mqtt": {
    "host": "mqtt://192.168.1.x",
    "port": 1883,
    "username": "username",
    "password": "password",
    "topicPrefix": "rinnai",
    "formatHomeAssistant": true,
    "publishCommandProcessed": true,
    "publishStatusChanged": true,
    "publishIntervals": true,
    "publishFrequency": 30
}

And here’s a simple Zone Off and On, waiting about a minute between the two commands.

[6/19/2020, 6:35:17 AM] [Rinnai Touch] [INFO] TCP Connection: Open
[6/19/2020, 6:35:23 AM] [Rinnai Touch] [INFO] TCP Connection: Closed
[6/19/2020, 6:35:32 AM] [Rinnai Touch] [INFO] TCP Connection: Open
[6/19/2020, 6:35:39 AM] [Rinnai Touch] [INFO] TCP Connection: Closed
[6/19/2020, 6:35:42 AM] [Rinnai Touch] [INFO] Received: rinnai/switch/zone/c/set, Payload: off
[6/19/2020, 6:35:42 AM] [Rinnai Touch] [INFO] TCP Connection: Open
[6/19/2020, 6:35:45 AM] [Rinnai Touch] [INFO] Sending Command: N000084{"HGOM":{"ZCO":{"UE":"N"}}}
[6/19/2020, 6:35:46 AM] [Rinnai Touch] [INFO] Command succeeded. Took 1500 ms
[6/19/2020, 6:35:47 AM] [Rinnai Touch] [INFO] Publish: rinnai/switch/zone/c/get, Payload: off
[6/19/2020, 6:35:51 AM] [Rinnai Touch] [INFO] TCP Connection: Closed
[6/19/2020, 6:36:17 AM] [Rinnai Touch] [INFO] TCP Connection: Open
[6/19/2020, 6:36:24 AM] [Rinnai Touch] [INFO] TCP Connection: Closed
[6/19/2020, 6:36:33 AM] [Rinnai Touch] [INFO] TCP Connection: Open
[6/19/2020, 6:36:37 AM] [Rinnai Touch] [INFO] Received: rinnai/switch/zone/c/set, Payload: on
[6/19/2020, 6:36:37 AM] [Rinnai Touch] [INFO] Sending Command: N000085{"HGOM":{"ZCO":{"UE":"Y"}}}
[6/19/2020, 6:36:39 AM] [Rinnai Touch] [INFO] Command succeeded. Took 2066 ms
[6/19/2020, 6:36:44 AM] [Rinnai Touch] [INFO] TCP Connection: Closed
[6/19/2020, 6:36:47 AM] [Rinnai Touch] [INFO] TCP Connection: Open
[6/19/2020, 6:36:49 AM] [Rinnai Touch] [INFO] Publish: rinnai/switch/zone/c/get, Payload: on
[6/19/2020, 6:36:54 AM] [Rinnai Touch] [INFO] TCP Connection: Closed
[6/19/2020, 6:37:17 AM] [Rinnai Touch] [INFO] TCP Connection: Open
[6/19/2020, 6:37:24 AM] [Rinnai Touch] [INFO] TCP Connection: Closed

Seems to be a status delay for the HomeBridge interface also.

Version 2.4.3 has been released which should fix the bug that causes the publish delay after processing a command.

Thanks, @Mantorok. Status update response is back to how it was before 2.4.2.

Hey Rod - long time no see :wink:

Very similar setup to mine (just one less zone) - happy to provide advice via DM etc as needed.

Cheers,
Chris

@David_M, glad to hear its fixed now.

@FrontBottom, have you tried using their latest version of the plugin with your evap cooling? I’m curious to know how well (or not) it works.

Hey @Mantorok - i promise the next time the weather gets over 15 degrees, I’ll turn off the heater and put the evap on for a few seconds :slight_smile: The next week isn’t looking good!

Hey @David_M (@Mantorok)

Not sure what I’m doing wrong (but I assume David has it working?)

One the overall “mode”, when I try and set it via HA Climate control, I get an error in the plugin. e.g

[6/20/2020, 10:14:37 AM] [Rinnai Touch] [INFO] Received: homeassistant/brivis/hvac/mode/set, Payload: heat
[6/20/2020, 10:14:37 AM] [Rinnai Touch] [DEBUG] HomeAssistantClient.process(hvac/mode/set,heat)
[6/20/2020, 10:14:37 AM] [Rinnai Touch] [DEBUG] HomeAssistantClient.setMode(heat,)
[6/20/2020, 10:14:37 AM] [Rinnai Touch] [ERROR] TypeError: Cannot read property 'toUpperCase' of undefined
    at HomeAssistantClient.setMode (/homebridge/node_modules/homebridge-rinnai-touch-plugin/mqtt/HomeAssistantClient.js:371:43)
    at HomeAssistantClient.process (/homebridge/node_modules/homebridge-rinnai-touch-plugin/mqtt/HomeAssistantClient.js:229:26)
    at MqttClient.<anonymous> (/homebridge/node_modules/homebridge-rinnai-touch-plugin/mqtt/ClientBase.js:41:26)
    at MqttClient.emit (events.js:315:20)

Looking at the code, I think the pluging is looking for a mode/set “heat”: “On”, versus what HA is sending - which is just “heat”.

@Mantorok - did this change since 2.4.1 - and @David_M - if it works for you, can you please share your yaml.

Cheers

@FrontBottom - you’re right. I haven’t been able to get the HA MQTT Thermostat working either, and I thought it was just me! I’ve just been focusing on individual MQTT mode ‘switches’ which work fine, but I’ve had another look now and can see it must be a problem with the topic.

@Mantorok - here are some additional logs. This is generated when anything is sent to rinnai/hvac/mode/set

[INFO] Received: rinnai/hvac/mode/set, Payload: heat
[6/20/2020, 11:11:33 AM] [Rinnai Touch] [DEBUG] HomeAssistantClient.process(hvac/mode/set,heat)
[6/20/2020, 11:11:33 AM] [Rinnai Touch] [DEBUG] HomeAssistantClient.setMode(heat,)
[6/20/2020, 11:11:33 AM] [Rinnai Touch] [ERROR] TypeError: Cannot read property 'toUpperCase' of undefined
    at HomeAssistantClient.setMode (/homebridge/node_modules/homebridge-rinnai-touch-plugin/mqtt/HomeAssistantClient.js:371:43)
    at HomeAssistantClient.process (/homebridge/node_modules/homebridge-rinnai-touch-plugin/mqtt/HomeAssistantClient.js:229:26)
    at MqttClient.<anonymous> (/homebridge/node_modules/homebridge-rinnai-touch-plugin/mqtt/ClientBase.js:41:26)
    at MqttClient.emit (events.js:310:20)
    at MqttClient._handlePublish (/homebridge/node_modules/homebridge-rinnai-touch-plugin/node_modules/mqtt/lib/client.js:1269:12)
    at MqttClient._handlePacket (/homebridge/node_modules/homebridge-rinnai-touch-plugin/node_modules/mqtt/lib/client.js:409:12)
    at work (/homebridge/node_modules/homebridge-rinnai-touch-plugin/node_modules/mqtt/lib/client.js:320:12)
    at Writable.writable._write (/homebridge/node_modules/homebridge-rinnai-touch-plugin/node_modules/mqtt/lib/client.js:334:5)
    at doWrite (/homebridge/node_modules/homebridge-rinnai-touch-plugin/node_modules/readable-stream/lib/_stream_writable.js:428:64)
    at writeOrBuffer (/homebridge/node_modules/homebridge-rinnai-touch-plugin/node_modules/readable-stream/lib/_stream_writable.js:417:5)

Thats amazing David. @ 10k i’ve just had a 4 zone brivis (Rinnai) system with the NC7 touch and touch wifi installed. I’d love to be able to use your floorplan solution, i had no idea you could use floorplan like that. I’m not a wizz like you but keen to give it a crack. Cheers Rob

Here you go @rgoodworth.home. This should get you started with the ‘floorplan’ display. I’ll upload any updates as I progress with it. I’ve got to go buy a half decent tablet to test it on soon, so there may be some more optimisations to make.

Glad it isn’t just me. I’ve been doing the switches also. Just trying to work out a nice way to present it.

image

The simple On/Off works ok - but have been playing with a custom button-card (for the first time) to present a bit more status info on the single button… Will see how we go.

Cheers

@FrontBottom, yep there’s a bug with the plugin. Two methods with the same name. Shouldn’t take long to fix.

Version 2.4.4 of the plugin is now available which fixes the MQTT hvac/mode/set bug

1 Like

@David_M, how did you go installing the NT-1 sensor? Do you have the ZonePlus module? I’m thinking of adding something like this too as I found the temperature distribution about the house very inconsistent.

I’ve also been thinking about how to show which zones are actively heating/cooling in the Home app and may have a possible solution. The plugin could add a “Temperature Sensor” accessory for each zone. This would show the temp in each zone but it would be 0.0 if the module doesn’t include it in its status. The accessory also has an Active/Inactive state which should show in the Home app as a lit or unlit tile. In the case of the Rinnai Touch when AE = Y then the tile would be lit and unlit then AE = N.

What do you think?

EDIT: I had a quick play to see how this sensor works and unfortunately it doesn’t work the way I had hoped. It will display the current temp but the “Status Active” characteristic is just a Yes/No field in the configuration screen. It doesn’t affect if the tile is lit/unlit. :frowning_face:

Not sure that fixed it.

[6/21/2020, 1:32:46 AM] [Rinnai Touch] [INFO] Received: homeassistant/brivis/hvac/mode/set, Payload: heat
[6/21/2020, 1:32:46 AM] [Rinnai Touch] [DEBUG] HomeAssistantClient.process(hvac/mode/set,heat)
[6/21/2020, 1:32:46 AM] [Rinnai Touch] [DEBUG] HomeAssistantClient.setMode(heat,)
[6/21/2020, 1:32:46 AM] [Rinnai Touch] [ERROR] TypeError: Cannot read property 'toUpperCase' of undefined
    at HomeAssistantClient.setMode (/homebridge/node_modules/homebridge-rinnai-touch-plugin/mqtt/HomeAssistantClient.js:371:43)
    at HomeAssistantClient.process (/homebridge/node_modules/homebridge-rinnai-touch-plugin/mqtt/HomeAssistantClient.js:229:26)
    at MqttClient.<anonymous> (/homebridge/node_modules/homebridge-rinnai-touch-plugin/mqtt/ClientBase.js:41:26)

Lookiing at the code where the error is, my interpretation is that you are expecting “heat/something”,

        let mode = topic.split('/')[1].toUpperCase();

whereas the topic is just “heat” (in this instance).

[DEBUG] HomeAssistantClient.setMode(heat,)

@FrontBottom, can you confirm that HomeAssistantClient.js has one method named setMode(payload) and another named setModeSwitch(topic, payload). Prior to 2.4.4 the 2nd method was named setMode(topic, payload).

Looking at your log it appears its still calling the old method as the 2nd parameter is undefined: HomeAssistantClient.setMode(heat,). If its calling the correct one the log should look like HomeAssistantClient.setMode(heat) [ie. without the comma]

Also, the setMode(payload) method does not contain this line of code:

let mode = topic.split('/')[1].toUpperCase();

You can see my change here on GitHub: https://github.com/mantorok1/homebridge-rinnai-touch-plugin/commit/7cd12c56badd8f64c5a16bdf52d389e0ad4178da#diff-56396ccb0584e2cf8884a9f51535389b

Howdy - definitely running v2.4.4 and it does have that setMode method taking the single parmater, and looking at the trace above, it seems to be calling the right one at this spot

<<Was just about to go into analsysi of how it was weird, as I am diefnitely running the right version, but it is making that call to the non-existant setMode method with two arguments… but to be safe I just restarted Homebridge and now all good!>>