Add protocol 278 'omni.c' device driver for microcontroller multisensor protocol #3278
Conversation
|
Thanks! Quick note: output_fields and |
|
Thanks. I figured that out but can't figure out how to do what I was
trying to do.
I wanted 'omni' as a single device, with a single signaling pattern but
with multiple possible internal data field formats. In particular, I
didn't want to have to declare separate protocols for 'omni00',
'omni01', ... 'omni15'.
That way, if someone wanted to add a protocol for their own use, they
could simply add the decoder section and recompile, without editing
rtl_433_devices.h, for example.
And the rtl_433 protocol list wouldn't be cluttered with 15 redundant
protocols.
So I developed the code without the qualifier 'const' for 'r_device
omni', and I change its omni.field value dynamically when the format
(0..15) is known by the decoder. That also avoids the need to define
'r_device omni00', 'r_device omni01', ... 'r_device omni15' in the
source code. The code works just fine without 'const'.
But with 'const r_device omni', I can't dynamically assign the value for
'omni.fields' to be one of the 16 possible output field formats, and I
need to add multiple 'omnixx' devices to the protocol list.
I'll think about this a bit more. I considered using an index an array
of output fields for omni.field, but I can't see how to make that work,
either. If r_device is 'const', then the dynamic assignment just won't
work.
If you can think of a way around this, please let me know.
David
|
|
I didn’t understand how “just list all possible keys in one output_fields” would work. I’ll go back and look again. Thanks
|
|
The |
|
It needs to be |
|
Pausing pull request to resolve a possible issue |
|
Reinserted a whole block of code that was missing & rechecked that |
|
Done.
…On 6/1/25 4:54 PM, Christian W. Zuckschwerdt wrote:
***@***.**** commented on this pull request.
------------------------------------------------------------------------
In src/devices/omni.c
<#3278 (comment)>:
> + // Make the data descriptor
+ /* clang-format off */
+ data = data_make(
+ "model", "", DATA_STRING, "Omni Multisensor",
+ "id", "Id", DATA_INT, id,
+ "channel", "Format", DATA_INT, message_fmt,
+ "temperature_C" , "Core Temperature", DATA_FORMAT, "%.2f ˚C", DATA_DOUBLE, itemp_c,
+ "voltage_V", "VCC voltage", DATA_FORMAT, "%.2f V", DATA_DOUBLE, volts,
+ "payload", "Payload", DATA_STRING, hexstring,
+ "mic", "Integrity", DATA_STRING, "CRC",
+ NULL);
+ /* clang-format on */
+ break;
+
+ case OMNI_MSGFMT_01:
+ itemp_c = ((double)((int32_t)(((((uint32_t)b[1]) << 24) | ((uint32_t)(b[2]) & 0xF0) << 16)) >> 20)) / 10.0;
My notes are suggestions for things you have to change.
If you need a sign-extend then write it like the rest of the decoders
have it, with a comment.
|int temp_raw = (int16_t)((b[1] << 8) | (b[2] & 0xf0)); // uses
sign-extend float temp_c = (temp_raw >> 4) * 0.1f; |
—
Reply to this email directly, view it on GitHub
<#3278 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJWBXCVL57Q7TQYCQ7T5HT3BNSBZAVCNFSM6AAAAAB5MF7ALSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDQOBWGEYDOOJUGA>.
You are receiving this because you modified the open/close
state.Message ID:
***@***.***>
|
hdtodd
changed the title
|
Renumbered to Protocol 278 |
|
I saw that apator was added as protocol 277, so I needed to renumber mine. I worked through the merge conflicts to move omni to 278 in ./include/rtl_433_devices.h (by position there after aptor) and in ./conf/rtl_433.example.conf. After a cmake rebuild, rtl_433 didn't recognize my omni devices. So I did a rtl_433 still didn't recognize omni. So I reverted: made omni as protocol 277 and apator as 278 by editing rtl_433_devices.h and rtl_433.example.conf. Removed the build directory and rebuilt with cmake and recompiled. rtl_433 then recognized my omni devices. I moved my rtl_433 directory aside, cloned a fresh merban/rtl_433 again, followed the instructions for adding a new decoder, and compiled it. rtl_433 -R shows that protocol 278, 'omni', is supported, but in operation, it doesn't decode my omni devices. If I again, in this new directory tree, reverse the positions and protocol numbers of omni and apator, rtl_433 does recognize it. In both cases, where rtl_433 does and doesn't recognize the omni protocol, I've tried to follow https://github.com/merbanan/rtl_433/blob/master/docs/CONTRIBUTING.md and BUILDING.md, but I'm obviously missing some step. Anything obvious? |
|
Running with some fictitious test data, e.g. |
|
First, thanks for the new trick ... hadn't noticed how to use '-y'.
It'll be handy to have as a tool.
Second, thanks for checking. The '-y' decodes when I have omni as 277
and apator as 278, but rtl still isn't decoding and publishing omni broadcasts on
the MQTT feed.
And when I put them in correct order and recompile, with apator at 277
and omni at 278, it decodes with '-y', but broadcasts from remote devices are not published as decoded messages in the JSON MQTT feed although with '-A' the pulse patterns are recognized correctly.
I think that switch of protocol #'s was the only change I made, and a
diff suggested that that was true. But something's wrong. I'll go think
about it some more.
Oh, I once found a parameter called MAX_PROTOCOL or PROTOCOL_MAX or
something like that that had to be increased, but I can't find that. Is
there such a parameter that I should be changing?
…On 6/3/25 4:15 PM, Christian W. Zuckschwerdt wrote:
*zuckschwerdt* left a comment (merbanan/rtl_433#3278)
<#3278 (comment)>
Running with some fictitious test data, e.g. |-y
"091112223344556677eb/091112223344556677eb"| seems to work fine:
|model : Omni-Multisensor Id : 9 Format : 0 Core Temperature: 27.40 ˚C
VCC voltage: 4.19 V Payload : 1112223344556677 Integrity : CRC |
—
Reply to this email directly, view it on GitHub
<#3278 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJWBXBACQFKU2QXTVODVWL3BX67DAVCNFSM6AAAAAB5MF7ALSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMZXGA2TCOBSG4>.
You are receiving this because you modified the open/close
state.Message ID: ***@***.***>
|
|
Re MQTT: Some of the keys are not in the correct format, e.g. |
|
Ah, I see, "light %" rather than "Light %". Fixed just now |
|
What I meant is that |
|
Got it. Done & in checks. |
|
I did a "git pull merbanan master" and recompiled with omni as 278 and apator as 277, and the decoder still fails to recognize the device broadcasts or publish via MQTT. I made omni be 277 and apator be 278, did a "rm -rf build", recreated ./build, and recompiled, and the decoder recognized device broadcasts and published via MQTT. I looked at the apator signal timings, and I don't see how they could be misinterpreted as omni's and so maybe take precedence for recognition. But I haven't studied how rtl_433 matches signal patterns, so maybe I missed something there. In my attempt to find a maximum number of protocols in a configuration file, searches for 277, 278, MAX, and PROTO in ./src and ./include didn't find anything that should be changed. Any thoughts as to what else might be going on or where I should look? |
|
Decoders run isolated, there is no possible collision. I don't see any practical reason why the order would matter. The current PR decodes test data fine here. Did you check |
|
Yes, I did check with 'git status' for other files ... nothing. I even cloned the merbanan master, did a fresh install, added the omni decoder after apator, and got the same result. I'll try that again first thing in the morning. Thanks for thinking about this. I can't see any obvious problem, but I'm sure it's something I did by accident and simply didn't think about at the time. I'll do the fresh clone again tomorrow to start from scratch and see if it works that way. I'm not making much progress this way. |
|
I've run out of ideas to try. I spent the afternoon re-cloning and testing in various ways (log below), but I consistently have rtl_433 decoding omni devices if it's registered as 277 (before apator) and failing to decode them if it's after apator (apator as protocol number 277, omni as protocol number 278). It makes no sense to me, but I need a break this. If you think of anything else to try, let me know. Oh, and I did notice in maintainer_update.py that MAX_PROTOCOLS is no longer computed, so I didn't imagine it in the past, but it's not needed any more.
|
|
Did you do a live test, or test with samples (cu8), or with a test code (-y)? Do you get the same (bad) results with all? Can you upload a sample as zip here? Test codes work and I can check a sample too. |
|
I did live tests. I just ran through the same set of build/test/edit/build/test ... sequence as yesterday, this time testing with '-y'. The '-y' tests DID decode (or, at least, the one for which I used the right command ... see the end of this posting). Except for that, I got the same results as yesterday: omni at 277 works; omni at 278 doesn't. I also tried it on one of the .cu8 files from the testing directory, and it also did NOT decode the signal. I only looked for the MQTT output yesterday. So today, I tried The .cu8, .ook, and .json testing files are in my rtl_433_tests/tests/omni directory, if you have access to that (there's a PR in for it). I'll zip them and try to upload them here after this message. Here's the log of what I did today. Note some of the problems with the directions for adding devices, mentioned in item 2 below. I ended up doing an Retesting my version of rtl_433Using my version of rtl_433 with omni as protocol 277 and apator as protocol 278, As transmitted from Pico 2 running omni.ino (live transmission):: 13:19:40.980 -> Transmit msg 7 iTemp=30.50˚C, oTemp=29.00˚C, iHum=49.00%, light=50.00%, Press=995.00hPa, VCC=4.88volts in hex: 0x 19 13 11 22 31 32 26 DE BC 8E As reported on my Mac running {"time":"2025-06-06 13:19:40","protocol":277,"model":"Omni-Multisensor","id":9,"channel":1,"temperature_C":30.5,"temperature_2_C":29.0,"humidity":49.0,"light_pct":50.0,"pressure_hPa":995.0,"voltage_V":4.88,"mic":"CRC","mod":"ASK","freq":433.93981,"rssi":0.68382,"snr":24.09885,"noise":-24.0994}
time : 2025-06-06 13:26:29 Testing a fresh clone of merbanan/rtl_433Move my rtl_433 aside and download a fresh copy of merbanan/rtl_433, and create an rtl_433 with omni as the last device:
Testing that last version, which does decode '-y' but doesn't decode live broadcasts, I tried analyzing one of the .cu8 files from the tests directory, but it also wasn't decoded: |
|
Here are the testing files for one of the samples: g001_433.92M_250k.cu8.gz |
|
I can't think of any reason the protocol number might matter. I think the 277/278 is a red herring. Just your PR (at protocol 278) decodes fine: and Regarding Maybe just clone https://github.com/hdtodd/rtl_433.git don't change anythin, compile, install and run. It works here. |
|
Thanks for your patience and persistence. I started with your suggestion and the fresh copy did not decode the omni devices. So I went through my sequence of builds/re-builds again this morning and eventually found the problem. I had not updated my rtl_433.conf to include apator as 277 and omni as 278. Just that simple. I thought it had to be some dumb error on my part but couldn't find it. I've just done a I believe I've incorporated the latest set of comments into this version ('light_pct', and format). I've installed this version and restarted it as a service for my ISM devices and it seems to be running fine. Please let me know if there's anything else I need to do. Again, thanks for your patience and persistence. David |
The 'omni.c' driver decodes programmable microcontroller (Arduino, Pico2, etc.) transmissions to rtl_433. The protocol offers 16 possible sensor-data formats in an 8-byte payload.
Example microcontroller programs to generate omni-compatible transmissions for rtl_433 are available for Pico2 and Arduino.
Decoder output and signal data are available in
rtl_433_tests/test/omni.