RTL-433 Missed transmissions #1887
Labels
Comments
|
Signal reception with these can be hit or miss for some people, and is not as good as a rtl-sdr. Personally I find the range halved or worse for my devices. Also antenna orientation can play a factor in reception, and I find vertical is best. Also OMG has signal deduplication logic for rtl_433 signals to reduce the number of duplicative MQTT messages transmitted, is this possibly the case? |
|
Thank you for the rapid response.
The antenna is vertical. I tried it in the house where the sdr is first. I then moved it to within 3m and the response didn't improve.
I've turned on verbose logging. It sends a message every time that it shows an RF packet. The RFtoMQTT count goes up by 4 every 2 minutes (not sure if that's a count of packets).
{"active":3,"frequency":433.92,"rssithreshold":-91,"rssi":-102,"avgrssi":-100,"count":24,"ookthreshold":15}
{"active":3,"frequency":433.92,"rssithreshold":-91,"rssi":-99,"avgrssi":-100,"count":28,"ookthreshold":15}
I can't get the status 1 command to work (nor can I change the RSSIThreshold)
Before my Bresser 5-in-1 stopped transmitting temperature and humidity I was using this
matthias-bs/BresserWeatherSensorReceiver: Bresser 5-in-1/6-in-1/7-in-1 868 MHz Weather Sensor Radio Receiver for Arduino based on CC1101, SX1276/RFM95W or SX1262 (github.com)<https://github.com/matthias-bs/BresserWeatherSensorReceiver>
on a TTGO. It was rock steady at 30m.
I suspect that if I compile the Bresser software with 433.92MHz it won't work
…________________________________
From: Northern Man ***@***.***>
Sent: 02 February 2024 07:40
To: 1technophile/OpenMQTTGateway ***@***.***>
Cc: pmknowles ***@***.***>; Author ***@***.***>
Subject: Re: [1technophile/OpenMQTTGateway] RTL-433 Missed transmissions (Issue #1887)
Signal reception with these can be hit or miss for some people, and is not as good as a rtl-sdr. Personally I find the range halved or worse for my devices.
Also antenna orientation can play a factor in reception, and I find vertical is best.
Also OMG has signal deduplication logic for rtl_433 signals to reduce the number of duplicative MQTT messages transmitted, is this possibly the case?
—
Reply to this email directly, view it on GitHub<#1887 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AI5KPMYAIEOS2XCX525COYDYRSJ5ZAVCNFSM6AAAAABCVP7LFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRTGIZTAOJVGY>.
You are receiving this because you authored the thread.
|
|
Soryy forgot to say that the rssi in the string is -49
{"model":"Emax-W6","id":843,"channel":4,"battery_ok":1,"temperature_C":10.27778,"humidity":84,"wind_avg_km_h":7.2,"wind_dir_deg":129,"rain_mm":90,"uv":11,"light_lux":0,"mic":"CHECKSUM","protocol":"Emax W6, rebrand Altronics x7063/4, Optex 990040/50/51, Orium 13093/13123, Infactory FWS-1200, Newentor Q9, Otio 810025, Protmex PT3390A, Jula Marquant 014331/32, Weather Station or temperature/humidity sensor","rssi":-49,"duration":118000}
UV and lux don't change so I presume not implemented
…________________________________
From: Northern Man ***@***.***>
Sent: 02 February 2024 07:40
To: 1technophile/OpenMQTTGateway ***@***.***>
Cc: pmknowles ***@***.***>; Author ***@***.***>
Subject: Re: [1technophile/OpenMQTTGateway] RTL-433 Missed transmissions (Issue #1887)
Signal reception with these can be hit or miss for some people, and is not as good as a rtl-sdr. Personally I find the range halved or worse for my devices.
Also antenna orientation can play a factor in reception, and I find vertical is best.
Also OMG has signal deduplication logic for rtl_433 signals to reduce the number of duplicative MQTT messages transmitted, is this possibly the case?
—
Reply to this email directly, view it on GitHub<#1887 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AI5KPMYAIEOS2XCX525COYDYRSJ5ZAVCNFSM6AAAAABCVP7LFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRTGIZTAOJVGY>.
You are receiving this because you authored the thread.
|
|
A couple of comments your signal RSSI of -49 is good, so signals are being easily received the count indicates that a signal has been received and sent for decoding, so my working theory is that the de-duplicate logic is filtering them out as they are duplicates. I would suggest connecting a serial console or use the WebUI console to look at the log. It should show more |
|
This is the verbose log
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-91,"rssi":-113,"avgrssi":-100,"count":21141,"ookthreshold":15}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/RFtoMQTT msg: {"active":3,"frequency":433.92,"rssithreshold":-91,"rssi":-113,"avgrssi":-100,"count":21141,"ookthreshold":15}
V: [ WebUI ] unhandled topic RFtoMQTT
T: Enqueue JSON
T: Queue length: 3
T: Dequeue JSON
N: Send on /SYStoMQTT msg {"uptime":522021,"version":"v1.7.0","disc":false,"ohdisc":false,"env":"lilygo-rtl_433-fsk","freemem":116088,"mqttp":"1883","mqtts":false,"msgprc":15960,"msgblck":0,"maxq":4,"minmem":52092,"tempc":45,"freestck":1920,"eth":false,"rssi":-30,"SSID":"pkm-24m","BSSID":"1C:ED:6F:A2:46:C0","ip":"192.168.0.112","mac":"E8:6B:EA:25:24:B4","modules":["LilyGo_SSD1306","WebUI","rtl_433"]}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/SYStoMQTT msg: {"uptime":522021,"version":"v1.7.0","disc":false,"ohdisc":false,"env":"lilygo-rtl_433-fsk","freemem":116088,"mqttp":"1883","mqtts":false,"msgprc":15960,"msgblck":0,"maxq":4,"minmem":52092,"tempc":45,"freestck":1920,"eth":false,"rssi":-30,"SSID":"pkm-24m","BSSID":"1C:ED:6F:A2:46:C0","ip":"192.168.0.112","mac":"E8:6B:EA:25:24:B4","modules":["LilyGo_SSD1306","WebUI","rtl_433"]}
T: Dequeue JSON
N: Send on /SSD1306toMQTT msg {"onstate":true,"brightness":50,"display-flip":true,"idlelogo":true,"log-oled":false,"json-oled":true}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/SSD1306toMQTT msg: {"onstate":true,"brightness":50,"display-flip":true,"idlelogo":true,"log-oled":false,"json-oled":true}
V: [ WebUI ] unhandled topic SSD1306toMQTT
T: Dequeue JSON
N: Send on /WebUItoMQTT msg {"displayMetric":true,"webUISecure":true,"displayQueue":0}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/WebUItoMQTT msg: {"displayMetric":true,"webUISecure":true,"displayQueue":0}
V: [ WebUI ] unhandled topic WebUItoMQTT
T: isAdupl?
T: Enqueue JSON
T: Queue length: 1
T: Min ind: 2
T: store code : 845 / 522140049
T: Col: val/timestamp
T: mem code : 845 / 521990051
T: mem code : 845 / 522020050
T: mem code : 845 / 522140049
T: mem code : 845 / 520250032
T: mem code : 845 / 520340033
T: mem code : 845 / 521090040
T: mem code : 845 / 521150041
T: mem code : 845 / 521180040
T: mem code : 845 / 521540042
T: mem code : 845 / 521570043
T: mem code : 845 / 521810048
T: mem code : 845 / 521960048
T: Dequeue JSON
N: Send on /RTL_433toMQTT/Emax-W6/4/843 msg {"model":"Emax-W6","id":843,"channel":4,"battery_ok":1,"temperature_C":2.05556,"humidity":92,"wind_avg_km_h":5.2,"wind_dir_deg":88,"rain_mm":90.4,"uv":11,"light_lux":0,"mic":"CHECKSUM","protocol":"Emax W6, rebrand Altronics x7063/4, Optex 990040/50/51, Orium 13093/13123, Infactory FWS-1200, Newentor Q9, Otio 810025, Protmex PT3390A, Jula Marquant 014331/32, Weather Station or temperature/humidity sensor","rssi":-51,"duration":117000}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/RTL_433toMQTT/Emax-W6/4/843 msg: {"model":"Emax-W6","id":843,"channel":4,"battery_ok":1,"temperature_C":2.05556,"humidity":92,"wind_avg_km_h":5.2,"wind_dir_deg":88,"rain_mm":90.4,"uv":11,"light_lux":0,"mic":"CHECKSUM","protocol":"Emax W6, rebrand Altronics x7063/4, Optex 990040/50/51, Orium 13093/13123, Infactory FWS-1200, Newentor Q9, Otio 810025, Protmex PT3390A, Jula Marquant 014331/32, Weather Station or temperature/humidity sensor","rssi":-51,"duration":117000}
T: Enqueue JSON
T: Queue length: 1
T: Enqueue JSON
T: Queue length: 2
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-91,"rssi":-99,"avgrssi":-100,"count":21145,"ookthreshold":15}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/RFtoMQTT msg: {"active":3,"frequency":433.92,"rssithreshold":-91,"rssi":-99,"avgrssi":-100,"count":21145,"ookthreshold":15}
V: [ WebUI ] unhandled topic RFtoMQTT
T: Enqueue JSON
T: Queue length: 3
T: Dequeue JSON
N: Send on /SYStoMQTT msg {"uptime":522141,"version":"v1.7.0","disc":false,"ohdisc":false,"env":"lilygo-rtl_433-fsk","freemem":116052,"mqttp":"1883","mqtts":false,"msgprc":15964,"msgblck":0,"maxq":4,"minmem":52092,"tempc":45,"freestck":1920,"eth":false,"rssi":-30,"SSID":"pkm-24m","BSSID":"1C:ED:6F:A2:46:C0","ip":"192.168.0.112","mac":"E8:6B:EA:25:24:B4","modules":["LilyGo_SSD1306","WebUI","rtl_433"]}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/SYStoMQTT msg: {"uptime":522141,"version":"v1.7.0","disc":false,"ohdisc":false,"env":"lilygo-rtl_433-fsk","freemem":116052,"mqttp":"1883","mqtts":false,"msgprc":15964,"msgblck":0,"maxq":4,"minmem":52092,"tempc":45,"freestck":1920,"eth":false,"rssi":-30,"SSID":"pkm-24m","BSSID":"1C:ED:6F:A2:46:C0","ip":"192.168.0.112","mac":"E8:6B:EA:25:24:B4","modules":["LilyGo_SSD1306","WebUI","rtl_433"]}
T: Dequeue JSON
N: Send on /SSD1306toMQTT msg {"onstate":true,"brightness":50,"display-flip":true,"idlelogo":true,"log-oled":false,"json-oled":true}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/SSD1306toMQTT msg: {"onstate":true,"brightness":50,"display-flip":true,"idlelogo":true,"log-oled":false,"json-oled":true}
V: [ WebUI ] unhandled topic SSD1306toMQTT
T: Dequeue JSON
N: Send on /WebUItoMQTT msg {"displayMetric":true,"webUISecure":true,"displayQueue":0}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/WebUItoMQTT msg: {"displayMetric":true,"webUISecure":true,"displayQueue":0}
V: [ WebUI ] unhandled topic WebUItoMQTT
T: Enqueue JSON
T: Queue length: 1
T: Enqueue JSON
T: Queue length: 2
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-91,"rssi":-102,"avgrssi":-100,"count":21149,"ookthreshold":15}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/RFtoMQTT msg: {"active":3,"frequency":433.92,"rssithreshold":-91,"rssi":-102,"avgrssi":-100,"count":21149,"ookthreshold":15}
V: [ WebUI ] unhandled topic RFtoMQTT
T: Enqueue JSON
T: Queue length: 3
T: Dequeue JSON
N: Send on /SYStoMQTT msg {"uptime":522261,"version":"v1.7.0","disc":false,"ohdisc":false,"env":"lilygo-rtl_433-fsk","freemem":116088,"mqttp":"1883","mqtts":false,"msgprc":15967,"msgblck":0,"maxq":4,"minmem":52092,"tempc":45,"freestck":1920,"eth":false,"rssi":-30,"SSID":"pkm-24m","BSSID":"1C:ED:6F:A2:46:C0","ip":"192.168.0.112","mac":"E8:6B:EA:25:24:B4","modules":["LilyGo_SSD1306","WebUI","rtl_433"]}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/SYStoMQTT msg: {"uptime":522261,"version":"v1.7.0","disc":false,"ohdisc":false,"env":"lilygo-rtl_433-fsk","freemem":116088,"mqttp":"1883","mqtts":false,"msgprc":15967,"msgblck":0,"maxq":4,"minmem":52092,"tempc":45,"freestck":1920,"eth":false,"rssi":-30,"SSID":"pkm-24m","BSSID":"1C:ED:6F:A2:46:C0","ip":"192.168.0.112","mac":"E8:6B:EA:25:24:B4","modules":["LilyGo_SSD1306","WebUI","rtl_433"]}
T: Dequeue JSON
N: Send on /SSD1306toMQTT msg {"onstate":true,"brightness":50,"display-flip":true,"idlelogo":true,"log-oled":false,"json-oled":true}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/SSD1306toMQTT msg: {"onstate":true,"brightness":50,"display-flip":true,"idlelogo":true,"log-oled":false,"json-oled":true}
V: [ WebUI ] unhandled topic SSD1306toMQTT
T: Dequeue JSON
N: Send on /WebUItoMQTT msg {"displayMetric":true,"webUISecure":true,"displayQueue":0}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: tele/OMG433/WebUItoMQTT msg: {"displayMetric":true,"webUISecure":true,"displayQueue":0}
V: [ WebUI ] unhandled topic WebUItoMQTT
T: Enqueue JSON
T: Queue length: 1
T: Enqueue JSON
T: Queue length: 2
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-91,"rssi":-102,"avgrssi":-100,"count":21154,"ookthreshold":15}
T: jsonPubl - ON
The 'yellows' were sent at 10:42:21, 10:44:21 and 10:46:21
rtl-433 messages during that time period
{"time":"2024-02-08 10:42:48","model":"IMETEO-X6","id":843,"channel":4,"battery_ok":1,"temperature_C":2.05556,"humidity":92,"wind_avg_km_h":3.0,"wind_dir_deg":73,"rain_mm":90.4,"mic":"CHECKSUM"}
{"time":"2024-02-08 10:43:18","model":"IMETEO-X6","id":843,"channel":4,"battery_ok":1,"temperature_C":2.0,"humidity":92,"wind_avg_km_h":7.4,"wind_dir_deg":64,"rain_mm":90.4,"mic":"CHECKSUM"}
{"time":"2024-02-08 10:43:48","model":"IMETEO-X6","id":843,"channel":4,"battery_ok":1,"temperature_C":2.05556,"humidity":92,"wind_avg_km_h":6.6,"wind_dir_deg":67,"rain_mm":90.4,"mic":"CHECKSUM"}
{"time":"2024-02-08 10:44:18","model":"IMETEO-X6","id":843,"channel":4,"battery_ok":1,"temperature_C":2.05556,"humidity":92,"wind_avg_km_h":5.2,"wind_dir_deg":88,"rain_mm":90.4,"mic":"CHECKSUM"}
{"time":"2024-02-08 10:44:48","model":"IMETEO-X6","id":843,"channel":4,"battery_ok":1,"temperature_C":2.05556,"humidity":92,"wind_avg_km_h":5.6,"wind_dir_deg":45,"rain_mm":90.4,"mic":"CHECKSUM"}
{"time":"2024-02-08 10:45:18","model":"IMETEO-X6","id":843,"channel":4,"battery_ok":1,"temperature_C":2.05556,"humidity":92,"wind_avg_km_h":4.8,"wind_dir_deg":80,"rain_mm":90.4,"mic":"CHECKSUM"}
{"time":"2024-02-08 10:45:48","model":"IMETEO-X6","id":843,"channel":4,"battery_ok":1,"temperature_C":2.05556,"humidity":92,"wind_avg_km_h":4.2,"wind_dir_deg":0,"rain_mm":90.4,"mic":"CHECKSUM"}
{"time":"2024-02-08 10:46:18","model":"IMETEO-X6","id":843,"channel":4,"battery_ok":1,"temperature_C":2.0,"humidity":92,"wind_avg_km_h":5.0,"wind_dir_deg":65,"rain_mm":90.4,"mic":"CHECKSUM"}
The gaps between messages since 10:42 ro 11:15 are
8 minutes
4 minutes
10.5 minutes
4 minutes
1 minute
1 minute
30 seconds
2 minutes
Do the 'unhandled topics' mean anything?
Phil
…________________________________
From: Northern Man ***@***.***>
Sent: 08 February 2024 03:51
To: 1technophile/OpenMQTTGateway ***@***.***>
Cc: pmknowles ***@***.***>; Author ***@***.***>
Subject: Re: [1technophile/OpenMQTTGateway] RTL-433 Missed transmissions (Issue #1887)
A couple of comments
your signal RSSI of -49 is good, so signals are being easily received
the count indicates that a signal has been received and sent for decoding, so my working theory is that the de-duplicate logic is filtering them out as they are duplicates.
I would suggest connecting a serial console or use the WebUI console to look at the log. It should show more
—
Reply to this email directly, view it on GitHub<#1887 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AI5KPM63CBXQRE2ZKSLDFB3YSRDULAVCNFSM6AAAAABCVP7LFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZTGMZDCMJWGM>.
You are receiving this because you authored the thread.
|
|
Tks for the logs Rtl_433 and OMG are running different versions of the emax.c device decoder, and the rtl_433 version has updates to it for your device merbanan/rtl_433@0815dd1 Which fixes the lux issue I’m working on refreshing the device decoders, and should have an update in late spring with the latest version, for the reception issue, I did not see any duplicates being mentioned in the log so that’s positive. But as the device is using fsk I’m wondering if the receiver chip needs tuning for your device? The fsk receiver parameters are here - https://github.com/NorthernMan54/rtl_433_ESP/blob/f65f8a8c09d81f55c5235c9204a089c3ffc81867/src/rtl_433_ESP.cpp#L217 As I do not have access to your physical devices, I can not do any device specific tuning or offer recommendations on what to tweak. |
|
Thanks for that. I'll keep on running rtl-433 as the main source and try tweaking bits and let you know if I get any joy
…________________________________
From: Northern Man ***@***.***>
Sent: 08 February 2024 15:06
To: 1technophile/OpenMQTTGateway ***@***.***>
Cc: pmknowles ***@***.***>; Author ***@***.***>
Subject: Re: [1technophile/OpenMQTTGateway] RTL-433 Missed transmissions (Issue #1887)
Tks for the logs
Rtl_433 and OMG are running different versions of the emax.c device decoder, and the rtl_433 version has updates to it for your device ***@***.***<merbanan/rtl_433@0815dd1>
Which fixes the lux issue
I’m working on refreshing the device decoders, and should have an update in late spring with the latest version,
for the reception issue, I did not see any duplicates being mentioned in the log so that’s positive. But as the device is using fsk I’m wondering if the receiver chip needs tuning for your device?
The fsk receiver parameters are here - https://github.com/NorthernMan54/rtl_433_ESP/blob/f65f8a8c09d81f55c5235c9204a089c3ffc81867/src/rtl_433_ESP.cpp#L217
As I do not have access to your physical devices, I can not do any device specific tuning or offer recommendations on what to tweak.
—
Reply to this email directly, view it on GitHub<#1887 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AI5KPMZJ2SBHF2DZGEHQIRTYSTSYNAVCNFSM6AAAAABCVP7LFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZUGMYTINZUGQ>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
This issue is stale because it has been open for 90 days with no activity. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Before submitting a problem please check the troubleshooting section
https://docs.openmqttgateway.com/upload/troubleshoot.html
Describe the bug
I have a vanilla Altronics weather station. It transmits every 30 seconds and rtl-sdr in my Pi picks up the signal 30+ metres away. The TTGO Lora32 less than 3 metres away is inconsistent with the signals. Sometimes it will send a response 30 seconds after the previous one but then it can be 6 minutes to the next one.
To Reproduce
Steps to reproduce the behavior:
Install lilygo rtl_433-fsk bin to TTGO under Option 1
Expected behavior
A clear and concise description of what you expected to happen.
Response every 30 seconds
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: