search

cpainchaud / RFLink32

RFLink for ESP, with MQTT client
Other
134 stars 46 forks source link

Plugin_048 Not Updated To "New" Format #42

Open sjmellen opened 3 years ago

sjmellen commented 3 years ago

Curious as to why plugin_048 (for Oregon Scientific sensors, which are quite popular) was never refactored into what I believe is a new plugin format. Is there a technical reason why that's not possible OR has someone has already done it and I'm just not finding it OR has no-one has taken the time to do it. Sorry for such a basic question but I'm still trying to wrap my head around this fork of RFLink and why/how the plug-in format has modified from the original. Posted a similar question on the couin3/RFLink fork but thought I would ask here since this project seems to still be active.

cpainchaud commented 3 years ago

Hi, Sorry for the late response, I missed the notification (I have too many ;)

There is not exactly a new plugin format here, some tweaked changes only as 95% of the code should remain the same. This is until we effectively switch to a brand new system or decide RTL433 is good enough to be ported on ESP32 (see RTL433 branch of this project)

Do you have any issue with the Oregon plugin today? You are right to say its current state is a nightmare, it makes absolutely no sense. It needs to be re-rewritten by someone who has some of these device. Are you feeling confident enough to try it?

yndtrud commented 1 year ago

Hello.

I have an Oregon TH132N sensor.

Now I am rewriting Plugin_048.c. I would like to receive data from the sensor, for this I bought a Sonoff RF bridge. It turned out that the Oregon plug-in is in an extremely deplorable state. Alternative firmwares like OpenMQTTGateway don't support Oregon either (on ESP).

At this stage, I have corrected the data buffer parser code (temperature, humidity, battery, etc.). Unfortunately, I cannot guarantee that data from other sensors (not from TH132N) is parsed correctly. There is test data for them in the plugin source code. I used this data to fix the code. For TH132N (and compatible) I used my real sensor data.

2023-02-02_163210

There's another problem. Data comes very infrequently. Sensors send data quite often For example, you can simply do a reset or pull out / put the battery in - the sensor sent its state at startup, but in fact, the data will be received (RF part, i don't know) and successfully parsed (perhaps the decoder cannot form an adequate buffer from the data) 1 time for 20 sensor restarts

RFLink Radio/Signals or the Oregon decoder very rarely gives a buffer with data. To find the reason, I need to somehow see the receipt of signals, but RFLink does not send me anything when I call Serial.printf(WHY!!!????)! If the debug data is sent via sendRawPrint, then everything comes. The oregon plugin I'm testing on a computer via mockup (sample data). I do not know how to connect the debugger to the ESP !!!

Give advice:

  1. How to get Serial.print to work (putty.exe -serial COM4-sercfg 115200,8,n,1,X)
  2. How to debug code directly from VisualStudio (Code or Full/Paid/Pro)
  3. How to set up signals? Do the default settings work for all devices? I changed a bit and at some point good signals began to come more often.

When I finish, then share the plugin

yndtrud commented 1 year ago

Curious as to why plugin_048 (for Oregon Scientific sensors, which are quite popular) was never refactored into what I believe is a new plugin format. Is there a technical reason why that's not possible OR has someone has already done it and I'm just not finding it OR has no-one has taken the time to do it. Sorry for such a basic question but I'm still trying to wrap my head around this fork of RFLink and why/how the plug-in format has modified from the original. Posted a similar question on the couin3/RFLink fork but thought I would ask here since this project seems to still be active.

My fixes in this post: https://github.com/cpainchaud/RFLink32/issues/74