Added decoding for Blueline/Black and Decker Power Monitor #38
Conversation
… constants, Fixed incorrect edit to getopt, changed variable nomenclature to match proto description, setup the byte order correctly for id offset, fixed bug where VALID - packets were incremented, changed proto description to match new identifiers
|
Hi can you squash, rebase and re send the pull request ? |
|
I'm interested in the Blueline monitor. Is there a reason why this was never merged in, or what works needs to be done to get it into rtl_433? |
|
Interested in this, any updates? |
|
We need sample data before we can update and merge this code. Please grab samples and note the expected values in a README. Upload a zip here or PR on rtl_433_tests. |
|
I'll see if I can get that done. Thanks. |
|
Not sure if this helps but there is a good write up on this protocol here, including sample audio. I believe @radredgreen used this for his code. https://scruss.com/blog/2013/12/03/blueline-black-decker-power-monitor-rf-packets/ |
|
No code will be merged without any sample signals we can test against. Follow the instructions here: https://github.com/merbanan/rtl_433#supporting-additional-devices-and-test-data |
|
I have one of these devices and would like to record samples so the code can be merged. I'm not clear on the correct set of switches to properly record the sample. It appears I should use something like: If correct, I'll see what I can provide! |
|
|
|
The batteries rusted on the contacts so if I can repair it I'll post a recording. |
|
I've also been looking at getting my Blueline power meter working recently. The callback function in this pull request looks like it would decode the data I've been capturing, but the OOK PPM timings on my samples are substantially faster. I wonder if the manufacturer increased the bit rate on later models. I'm reworking this pull request into the newer rtl_433 code base to test on my device. When I get something nominally working I may submit a new pull request or at least put my changes up on a fork. I am also planning on capturing samples for rtl_433_test. One annoyance I've already noticed is that much of the information received over the radio, as well as being able to check the CRC itself, both require some prior knowledge of the monitor to be user friendly. I plan on reworking my version of the pull request to just report raw accumulated pulse counts and pulse rates, and some other application after rtl_433 will have to process that further using the meter's K-factor and historical pulse counts to convert to current kWh and total kWh. I'm not sure what to do about the CRC part, though. Blueline did a trick where the transmitter ID isn't actually broadcast as part of the data payload except when you manually hit a button on the transmitter to reset it, but you need to know the ID to validate the CRC on all the normal payloads. The idea is that any given receiver should permanently remember the ID of the unit it was setup to listen to, and be able to ignore data from other units since all their CRCs would fail. |
|
CapnBry did a bunch of work with this monitor and I believe it's correct. I took his working code and tweaked it for a different Arduino based, multi-protocol project several years ago. My project wasn't powerful enough (low signal received and the code seemed to break the Arduino over time) so, although it does function, it is not used any more. I think his code could be converted to a script or Node-Red flow. https://github.com/CapnBry/Powermon433/blob/master/arduino/Powermon433/Powermon433.ino CRC: This is a more recent issue that's related: And there's a ton of discussion I used long ago on this blog: |
|
You can upload samples directly to this ticket. |
|
Draft pull request in case anyone wants to see how things are going: |
No description provided.