Got another phone in the household? or next door neighbor?, see if you can get it set up and registered on their phone and then try to connect yours after connected.
I couldn’t get it connected on my phone, so I used an ipad to set it up and then added it to my phone once setup.
Thanks knackers24. I used my iPad and it worked a treat. The conenction between the Rinnai device and the router ‘broke’ a couple of times so I moved the router closer. You’ve saved me a lot of frustration. Helpful people on helful forums like this are great. Thanks again.
happy to help mate. Glad you got it going.
Hi,
I too have bought this wifi module and am trying to reverse engineer the API to integrate into a home automation controller. I’ve captured the same packet data as you between my iOS device and the wifi unit.
It appears as though this is not MQTT - MQTT is a binary wire protocol and the packet capture clearly shows a JSON payload.
Googling some of the keys like “SYST” and “HGOM” yields no meaningful results. I’m starting to think this is some kind of custom/proprietary API.
You are right though, you can work out some of the important items by eyeballing the data, e.g.
SYST = system
CFG = config
TU = temperature unit
VR = version
CV = module wifi version (this is shown in the app)
DY = day
TM = time
ZA … ZD = zone a … zone d
{“HGOM”: {“CFG”: {“ZUIS”: “N”, “ZAIS”: “Y”, “ZBIS”: “Y”, “ZCIS”: “N”, “ZDIS”: “N”, “CF”: “N”, “PS”: “Y”, “DG”: “W” } - this part tell you which zones you have - e.g. A and B are “Y” the rest are “N”
ZAO = zone A operation? (same for zone b, c and d - no idea what zone u is, perhaps universal?)
OP = operation (i assume “m” = manual)
SP = set point (set temp)
ZAS = sone A status ? (same for zone b, c and d - no idea what zone u is, perhaps universal?)
MT = measured temp (e.g. 226 = 22.6C?)
I don’t think much of the rest really matters - these are status packets that are sent regularly… you just need to pull out the bits you are interested in and display/use those and ignore the rest.
As for setting the temp, that message was simple:
{“HGOM”: {“ZAO”: {“SP”: “12” } } }
HGOM = no idea
ZAO = zone A operation
SP = set point (set temp)
There are really only a few commands that need to be figured out. On/off, set temp. I also have evap cooling so need to figure out how to switch modes and control that too!
Another observation is that all the JSON messages are prepended with a string - in your case “N000010”. In my case N000045 then N000046 - maybe some sort of incrementing message counter?
I’m also wondering how to establish a connection to this device… the port numbers seem somewhat random which suggests there is some sort of negotiation that occurs first (between the app and the cloud?) before the app connects directly to the device.
I’ll keep poking around and see what i find.
/JB
1 Like
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/