I’m using the built in recirc on my unit.
I have a schedule set up in the navilink app to run the recirc throughout the day (currently not the most efficient approach)
when water is flowing, (byte 18) the value of byte 8 is 8 for me.
I do see random spikes of 32, but I’m not sure what that is about… it could just be garbage data as I don’t have checksum validation in place yet.
Byte 18 as you mentioned on your GitHub readme, is “Flow rate - measured in 0.1 liters per minute (divide by 10 to get LPM)”. I do see this value change (drop) when a tap is turned on and off.
What I have been investigating is Byte 8.
Maybe a picture would illustrate what I see. The red circles is the Navien doing a heating cycle (The period and settings of this are configured through Pref 12, 14 & 15) with recirculation running but no tap is turned on.
The green circle is when I turned on the shower.
I am also fine moving this discussion to your GitHub. I can create an issue “Debugging water packet byte 8” and track the work/discussion there. I have ideas on other bytes too.
Top is byte_8
middle is byte_18
bottom is instant btus
From 12:50->1:00 the shower was running,
I have values of 32, instead of your value of 3.
at first I thought it was garbage data, but after looking at the times the shower was running, it seems to correlate with tap open.
The smaller hump around the 1:05, is recirc is running, but no taps are open.
That has a value of 8.
There must be a difference in how the 240A2 and 240 report the data, or a difference in how it is installed/configured. My unit has a built in recirculation pump, and I have a cross-over valve so the hot water cycles over the cold back to the unit.
Wish I knew why we get different values, going to make this harder to fully decode.
Was anyone able to get this to work with a Navien NPE-180A or NPE-180
On a side note in case this can help with deciding the hex data. I started learning about how logic analysis and came across this video of AI used to decode hex data: https://m.youtube.com/watch?v=x-kMQCyVMyI
You would need the data sheet. Has anyone taken the Navien apart or taken a look inside on the PCB board to see what chips are there and would that help with deciding?
I did at one point ill see if i can find the photos but what we need is what kind data it is outputting.
this is what is available from the gui on the controller
1 Like
NPE-180A should work. anything that can work with their navilink will
1 Like
for the hot button i added a relay to my esp32:
- platform: gpio
pin: GPIO19
name: "Hot Button"
id: relay
on_turn_on:
- delay: 500ms
- switch.turn_off: relay
and wired it into the hot button contact.
Hi, @raptordemon, would you have a photo of how you wired it to the hot contact? It would help get a picture of how it can be done. I’m worried about breaking my hot water tank if I mess up.
I think it is the best if we can maintain Yaml/CPP or any other versions but also have a clean documentation as a file - that’s why I started a separate doc outside of the implementation and welcome any contributions btw.
its just wired into CON2 as per the navien manual for the hot button. for the relay side it is the COM and the NO terminals.
1 Like
i was just reading over your work on the Checksum, you did a fantastic job there, nice work.
i am new to these concepts, i get that the checksum is used to verify the data was transferred correctly as a concept , can you explain how the checksum is used or how we should implement this in our code?
if it helps here is my values for the same entities, showers at 1am and 4am.
i have a navicirc thats on a schedule 6am-9am ish 11-1pmish and 5-midnight.
i agree that Byte 8 seems to be 32 when running full heat and 8 when doing recirc
“can you explain how the checksum is used or how we should implement this in our code?”
The checksum is used to verify that the data that came from Navien unit or sent by our devices is not mangled or damaged in transit. Now, in practical terms that will rarely happen (if ever) since the connection lines are relatively short. So, there is not as much practical value in verifying the checksum when received from Navien. Practically speaking one can just ignore the checksum when receiving statistics. However, checksums are critical when sending data to Navien and, in particular, if one attempts to set the temperature. In doing so we need to compute a packet (sequence of bytes) that has necessary byte values to set the temperature and also compile the correct checksum. If checksum is not present or incorrect the Navien unit will reject the packet, i.e. consider it damaged and, therefore, the command will not apply.
Now, an interesting side effect of Navien protocol is that when sending static commands that don’t have user define values (temperature and may be others) it is possible to just capture and resend what Navien Wifi Lite or other controllers normally use. For example, on/off or hot button commands always translate to exactly the same byte sequence (same packet). One can capture what the “real” Navien devices send and just send that - no need for any calculations.
Does this make sense? I’d be happy to explain if not - feel free to ask…
1 Like
BTW, I’ve added a new section in the git, explaining how to connect to STM32 processor in the Navien Wifi Lite to debug the code/protocol in case if anyone is interested - navien/doc/navien_wifi_debug.md at ca4f5e90c1ce9808bbf9f76f270107d61642d22a · htumanyan/navien · GitHub
2 Likes
got it thanks for the explanation
WByte9 power state seems to match my recirculation schedule with 5 being standby and 37 being recirculation
text_sensor:
- platform: template
name: "Water Heater State"
id: water_heater_state
lambda: |-
if (id(uart_water_byte9).state == 5) {
return std::string("Standby");
} else if (id(uart_water_byte9).state == 37) {
return std::string("Recirculation");
} else {
return std::string("Unknown");
}
update_interval: 1s
BTW, raptordemon, is there a chance you could take high quality pictures of the front and back of the hot button board? I am trying to figure out where to take the power in Navien versions that do not have the +5V at the connectivity jack - might be able to get some clues if looked closely at the traces on the hot button board. Completely understandable if it is inconvenient, but I thought it would be worth asking…
ill take some pics shortly. for now here is from the manual:
full manual is here: Hotbutton-Installation-Instructions-EN | Downloads | Navien
i see, you want what pin on CON5 has 5v?
here are the pictures you requested, i buzzed out the 5v terminal with a multi meter and it goes to what seems to be a voltage regulator. my guess it they give the hot button board 12v and it generates the 5v. the hot button signal seems to go into an optocoupler.
i have a 210-A2 so this is not the one that comes in the kit but the version that comes with the 210/240-A2