Latest UDP Protocol

Projects
, ,
1

Is there a link to the latest UDP protocol? I’m struggling with the vs 1.0.30 which I don’t think is the latest for the latest Core+K9

2

Hi,

Here is the link to the WatchMon UDP Listener that we regularly update with the mapping of the messages:
https://github.com/Batrium/WatchMonUdpListener

Make sure to go directly to the Payload folder for the latest release: https://github.com/Batrium/WatchMonUdpListener/tree/master/payload

Meanwhile, the up-to-date WatchMon Toolkit Software Releases are found on our Wiki: https://wiki.batrium.com/en/software

3

Ah perfect thanks! I can use that git repo for what I need.

Best regards,

Ross

4

Hello @maxine,

Is the WatchMon UDP repository on GitHub still maintained? I notice that the latest commit is two years old and there are a few (one year+ old) issues that are not addressed.

5

Hello osaether,

Yes, this is maintained. But we have not updated any messages in the last two years and there are no new features other than the new CAN inverter options, which didn’t require any payload changes.

This is intentional as we’ve been limiting the payload changes. Because when we do so, it breaks a lot of people’s systems where they’ve written their own applications to listen to the data transmitted from the BMS.

Hope this has been helpful!

6

You said the UDP messages have not changed but the Msg_4733_TelemetryCtrLogicStatus data does not match up with the info on GitHub. I did some testing and mapped the Expansion relays and SSR’s as well as the SoC% data and have that working but not sure how much of the other data does not align. Also there are a number of messages that are not listed in the repository 3031, 5a32, 3033, 5b31, 5a31, 5932 & 5931… If you could please provide an update for Msg_4733 that would be great, this is what I have tested so far:

.bit1('hasSocLoTriggered2')         // boolean index 30 - bit2
.bit1('isSocOnState2')              // boolean index 30 - bit3
.bit1('hasSocHiTriggered2')         // boolean index 30 - bit4
.bit1('hasSocLoTriggered1')         // boolean index 30 - bit5
.bit1('isSocOnState1')              // boolean index 30 - bit6
.bit1('hasSocHiTriggered1')         // boolean index 30 - bit7
.bit1('reserved10')                 // boolean index 31 - bit0
.bit1('reserved11')                 // boolean index 31 - bit1
.bit1('hasSocLoTriggered4')         // boolean index 31 - bit2
.bit1('isSocOnState4')              // boolean index 31 - bit3
.bit1('hasSocHiTriggered4')         // boolean index 31 - bit4
.bit1('hasSocLoTriggered3')         // boolean index 31 - bit5
.bit1('isSocOnState3')              // boolean index 31 - bit6
.bit1('hasSocHiTriggered3')         // boolean index 31 - bit7
.bit1('ExpansionOutputRelay4')      // boolean index 32 - bit0
.bit1('ExpansionOutputRelay3')      // boolean index 32 - bit1
.bit1('ExpansionOutputRelay2')      // boolean index 32 - bit2
.bit1('ExpansionOutputRelay1')      // boolean index 32 - bit3
.bit1('ExpansionOutputSSR8')        // boolean index 32 - bit4
.bit1('ExpansionOutputSSR7')        // boolean index 32 - bit5
.bit1('ExpansionOutputSSR6')        // boolean index 32 - bit6
.bit1('ExpansionOutputSSR5')        // boolean index 32 - bit7
.bit1('reserved12')                 // boolean index 33 - bit0
.bit1('RelayA')                     // boolean index 33 - bit1
2 Likes
7

Hi @James,
I just wanted to implement full monitoring of my battery pack. I forked the WatchMonUDPListener (GitHub - kleini/WatchMonUdpListener: WatchMon UDP Binary Listener translates to JSON and stores to influxdb), included some fixes of other forks and try to make it now usable for me.

As stated in the previous message, the payload parsers for messages with message ID 3031, 3033,
5034, 5931, 5932, 5a31, 5a32, 5b31 are missing. I would like to add those.

Furthermore, I think it would be useful to have a ready to use container image in some container image registry. I am going to implement a GitHub Actions pipeline building that image.

Are you interested in providing me the necessary information to make the WatchMonUDPListener more usable? I read about the MQTT protocol, you’re implementing. But I think, this still might take some time for finishing. Having a fully working WatchMonUDPListener instead in place is maybe helpful. What do you think?

Kind regards,
Kleini

2 Likes
8

Im having some problems with this my self.
I have tried several different imports to my node-red, but havent yet seem to find out whats wrong or how to fix it.
Some updates on this would/could be helpful :slight_smile:
And the MQTT would also be amazing, but i fear thats going to take a while until we get our hands on it…

9

@titanium87 How is the UDP protocol related to Node-RED? The only possible listener for UDP broadcast messages of a WatchMonCORE is the WatchMonUdpListener. This can then publish the collected messages to MQTT and Node-RED can read these MQTT messages.

10

Note regarding Batrium WatchMonUDPListener:

A project that hasn’t seen a commit in four years has nothing to do with maintenance. The dependencies aren’t pinned, meaning that if there’s a breaking change to one of them, the Dockerfile will stop working. The Dockerfile specifies Node version 12. The latest version is from somewhere in the mid-2020s.

This has nothing to do with best practices or maintenance.
What are Batrium’s own aspirations/goals?

11

There is not the final answer but some possible answers for the current moment:

  1. MQTT is in the making:
  1. You can use BMI instead:
  1. I tried to collect all forks and updates for WatchMonUDPListener. Pull requests are welcome!
12

Hi SCE,

The community member we collaborated with on the WatchMonUDPListener stopped maintaining it after a while, and we are moving as fast as we can away from that and towards a more neutral, open format that can be run through something simpler like Node-RED.

Our original repo should really be archived by now, I’ll see if I can get that done so it’s more obvious.

Side note, it has kept our internal protocol stranded and limited the features we can push out, another reason we are very keen to move away from it.