Having said that, both yours and mine connected on TCP port 27847.
Brilliant I’m excited someone else is looking into this. You’re right if we could connect to the module it would not be hard to send the right messages. I had a look through the Android app again and I think HGOM means Heating Operation Mode, as there is also CGOM for Cooling. Here’s two files I extracted from the API.dll CHeating CCooling
Interesting find about MQTT, inside the Android app there are many libraries related to some sort of MQTT implementation, mostly labled CMQTT. I think it’s CloudMQTT possibly used to communicate through the internet. I also discovered a more recent feature of MQTT is communication over the Websockets protocol, which doesn’t use standard ports. It may also have TLS encryption. I found others online trying to decode TLS and it looked similar to what I was seeing in Wireshark - data starting with an encoded packet followed by a readable payload. I think that encoded packet may include the credentials and topic.
If it is MQTT or something else, I think there is a private key in the module, and public keys in the app. The only way I can imagine extracting the private key is if Brivis releases a firmware file, or if I can access a serial debug output from the module’s CC3220 board. I opened up the module (easily, its just 4 clips) but Brivis have created a custom board with no TX and RX labelled pins like the standard board has. My next step was to buy an oscilloscope and find the pins, but I can’t justify the cost. Anyway I’ll attach some screenshots of the MQTT and TLS references I found in DotPeek.
MQTT Screenshot 1
MQTT Screenshot 2
TLS Screenshot
If anyone else wants too look around
Rinnai Touch Android APK
How to Decompile
DotPeek
Nice work!
I think all the info we need to interact with the API locally is there. It appears that all of the MQTT/TLS code is required for remote, cloud access. Accessing the API from the local LAN appears to be a simple TCP-based protocol, defined in CWIFIAccess.cs - can you post that entire file somewhere?
Local LAN discovery involves listening for UDP packets on port 50000 and looking for a packet starting with the string “Rinnai_NBW2_Module”. The wifi module broadcasts these UDP packets to the local LAN once per second by the looks of it. This is a dump of it’s contents:
0000 52 69 6e 6e 61 69 5f 4e 42 57 32 5f 4d 6f 64 75 Rinnai_NBW2_Modu
0010 6c 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 le…
0020 6c c7 55 b7 0a 02 00 00 00 00 00 00 00 00 00 00 l.U…
0030 34 48 52 46 4d 56 33 52 30 56 00 00 00 00 00 00 4HRFMV3R0V…
0040 c7 bb 1d 1d 10 72 af b1 20 59 8d b7 37 a8 d3 65 …r… Y…7…e
0050 1a cf 85 71 ab 14 a8 98 4f c7 c4 35 a5 fe 84 64 …q…O…5…d
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
The first 2 bytes of location 0020 (6c c7) equals 27847 which is the TCP port used to connect to the module. I’m sure the other data is used for something as well (authentication perhaps?). These UDP broadcasts tell us everything we need to know in order to connect to the API over TCP - most of which should be defined in your CWIFIAccess.cs file.
I’ll play around with it a little more later tonight when I have some time.
This is excellent news. Here is the CWIFIAccess.cs
I’ve noticed it contains the ‘HELLO’ message that I see in wireshark, but I don’t understand much else in there unfortunately. I see that it may be using some sort of authentication
this.DeviceDefaultPassord = Encoding.UTF8.GetString(e.RxPacket.Buffer, 48, 10);
public string DeviceDefaultPassord { get; private set; }
Where this password is I don’t know.
EDIT: These also seem related to the local connection CNetworker.cs CNBWControl.cs
I might try this when I have the chance -
Hi mate. Thought I’d try my luck again with some assistance. When the module works it’s great, but all too often, when away from home and trying to access the heating/air con system remotely using the app, I get the “Connection Not Found Screen” on the iPhone. I can try several times during a day and no connection and then all of a sudden a connection is found. I’ve tried both 4G and wi-fi with good signals. It seems that the original configuration is correct but that the connection to the module is a bit hit and miss. Any tips? Has there been a firmware upgrade to the module maybe?
Hey George, I have no issues across any of my devices. Is your module too far away from your WiFi access point maybe? Thats the only thing I can think of, mine is rock solid 24/7.
My module is about 5-6 metres from the wifi router. I might try and get it closer. How close is yours mate?
Probably about 5m from 1 of my APs and maybe 10m from the other one.
It is also not just how far away, but do you have anything that could interfere with WiFi signals, is it running through brick walls, glass, etc. Is it a crappy wifi modem from an ISP ? What standard are you running on your WiFi, etc etc
Sorry to trouble you again. I’ve just diagnosed part of the problem. As soon as I got home, I could access the module once my iPhone was on the home wifi network. As soon as I turn wifi off on the iPhone and rely on 4G, I fail to connect with the module. (I couldn’t access the module from work either using wifi).
I’ve tried this scenario using both my iPhone and iPad. So in summary, connects when on the same home wifi network with iPhone and iPad but no access externally. It certainly did work for a few days externally but it was hit and miss as mentioned earlier, but now not at all. The orange light on the module keeps flashing and there is no error message on the Touch Controller. Any suggestions please mate? Reconfigure??
Just an update here. I tried the ‘old’ switch off/switch back on process on the module almost as a last resort and it seems to have fixed the problem - for now at least.
Has anyone actually integrated this yet?
Nope if you know someone who can code a TCP handshake into a component then point them here 
Looks like interation is doable … hopefully we can work out how to do it for “free”!
Great so they’re asking $300 for their component/driver. If I buy the driver, upload it here, then cancel during the trial, I wonder if someone could use it to create a component for us.
EDIT: Not sure if it’s an error on their part - the page for their Brivis driver actually has a download link. Here’s a drive link incase they take it down -
driverworks_ip_rinnai.zip
You would still need to buy a licence for a Control 4 System, but if we can get inside the driver file it may have the code we need. Although looks like their driver files are encrypted - https://pushstack.wordpress.com/2016/03/06/control4-driver-decryption/
Bought one last night, so will soon join the group trying to work out how to link this in to HA. 
Awesome. I opened the driver zip and changed the .c4z file to a zip. Opened it and found the Code.lua.encrypted file. According to forums in 2018 they’ve updated the encryption so I don’t think the 2016 blog post method would work anymore.
Ok - just hit the button. $261 at this store on eBay at the moment …
Nice one. Do you have any ideas on how we could get it intergrated? It’s all beyond me sadly