Backlog for rtl_433-refresh branch aka next release #20
Comments
|
Currently not. Update: i got it -> rtl_433_ESP = https://github.com/NorthernMan54/rtl_433_ESP#rtl_433-refresh I have one more posible protocol confusion - Silvercrest remotes are recognized as SmokeDetectors :-D Example from MQTT: home/OpenMQTTGateway_rtl_433_ESP/RTL_433toMQTT/Smoke-GS558/9143 |
|
@NorthernMan54 - Thanks for the work, I haven't tested with my 868Mhz FSK weather station recently, but will test the new branch soon. Will also test with my currently running 434Mhz setup. |
|
@NorthernMan54 - Just am a bit confused when going through the commits of the rtl_433-refresh branch. With the changes I made for the SUPPRESS_UNPARSED option, which is still in the ReadMe, and the connected PUBLISH_UNPARSED in the rtl_433_ESP.cpp, you deleted in rtl_433_ESP.h with e03f689 Making the described SUPPRESS_UNPARSED flag non-working. Will you change the ReadMe to define the new optional flag as PUBLISH_UNPARSED, or was this an accidental deletion? |
|
@Dattel I spent some time digging further into your comment about unparsed messages happening at a higher frequency when the test button was pressed, and found that the device decoder was always reporting issues with the first bit of the received signal. And after comparing it with rtl_433 came to the conclusion that the first bit is just noise and can be ignored. @DigiH This applies to all signals, and I did do regression testing ( directly compared a rtl_433 with OMG running the latest version ) for the afternoon with my fleet of devices. No issues identified. From rtl_433_ESP From rtl_433 |
|
So shall i test the "manuall transmission" again with the latest build? |
|
Definitely |
|
Current used libs Each transmission (by button or automatically) results in one "parsed signal" followed by an "unparsed signal" randomly (very rare), no signal parsing occures |
|
@Dattel would you call that an improvement ? Looking at the raw signals, their is a tiny bit of noise triggering the unparsed Manually parsing one, it looks like this That is marked as unparsed, as the device decoder has some funky rules about # of rows and repeats If the signal has more than 4 rows, then 5 rows need to match, then only 3 need to match. ( lacrosse_tx141.c line 131 ) |
|
it's definitiv much better than before 👍 One remark - i think @DigiH already mentioned it - unparsed signales are still printed to terminal - independently to the compiler switch. |
|
Also much better results here for the reboots, running fine here for the last 3 days. 👍 @Dattel - the implementation for suppressing (now activating) unparsed signals was only really meant for MQTT messages (not)being published for these. The unparsed signals still showing in the serial terminal, I think, is fine for debugging, and would need a separate change if also wanting to be suppresed in terminal. |
|
not it's okay... |
|
Well, in the latest commit I stopped logging of unparsed messages to the serial output unless PUBLISH_UNPARSED is set. I also added the ability to enable device decoder verbose mode for a single device decoder |
|
From the list at the top of this issue, I think I'm ready to publish this as the final. I'm going to park item 3 and 4 for now. |
i think, that is very helpfull for the future 👍 |
|
Tks everyone for their assistance with this release, I have now merged the branch into the master via #18 Now to get openMQTTGateway updated as well |
|
This was released this morning |
This is the rtl_433-refresh branch
1 - Random reboot after approx 14 hours
- Serial monitor has this aka no exceptions, No memory leaks or stack leaks visible
- Further testing has shown the issue to be a wiring problem on my breadboard device aka loose connection
[x] Resolved
2 -
Flex decoder needs more work or write a contrib device decoder for sonoff PIR device[ ] - Enable flex decoder
[ ] - A definition option for flex decoder ( single pattern )
After further investigation and testing identified that the existing flex decoder is too resource intensive to work. ESP32 stack needed to be increased to 32768 in order to have flex_callback callable.
3 - Try signal strength detection method ( this was initially investigated as part of FSK feature )
- this may resolve #19
[ ] Complete
4 - Further investigation on the DEAF issue
- aka issue #16
5 - Update of CC1101 driver version, needs to be part of openMQTTGateway's development branch
- 2.5.7 is the latest
6 - Add to openMQTTGateway development branch
[x] Development testing was completed
7 - Update README for
PUBLISH_UNPARSEDsetting[x] Completed
@DigiH - anything else to add to the backlog ?
@Dattel @mozgy - anything else ?
The text was updated successfully, but these errors were encountered: