Let's Control It

Hi there,

the https://github.com/letscontrolit/ESPEas ... 111_RF.ino does not work in newest Espeasy and I want to update it to the latest EspEasy standards. This is the first time changing something in Espeasy/plugins sources, so I'm not really an expert on the topic. I only need to listen on the codes, if the code matches the code I expect (mailbox sensor, door sensor, etc. I don't need to extract any value from the code). The raw int code is enough for me.

I had to change Device[deviceCount].VType = Sensor_VType::SENSOR_TYPE_ULONG;

the problem I'm facing is the UserVar variable, where it was previously an Array, now it's a Struct:

old code (line 114-115):
my attempt was compiling okay, code is read properly and the valuerf contains correct code (is logged in log). but the problem is, Espeasy EVENT is fired with wrong (empty) value: my hesitations:
1. I'm not sure what is the TaskIndex compared with BaseVarIndex (what exactly are those and which one to use?).

2. valuerf var is of type int (but the code could be easily over 32bit long, but that's another story). I'm also not sure about the type of the value I should be storing to UserVar. I've tried to use setUint32() method of the UserVarStruct struct


does anybody have time for explanation, what I'm doing wrong or where are my thought going wrong way?

You should use setSensorTypeLong
I think P040 ID12 is a good source to compare as it also uses the same way of storing an 32 bit (unsigned) int.


About BaseVarIndex and TaskVarIndex... (or TaskIndex)

We have TASKS_MAX tasks in ESPEasy (12 for ESP8266, 32 for ESP32 builds)
Each task can have VARS_PER_TASK task values. (4)
The UserVar struct is an array of (TASKS_MAX * VARS_PER_TASK) float values.
So the TaskIndex is 0 ... < TASKS_MAX.
BaseVarIndex is TaskIndex * VARS_PER_TASK. Or in other words the start of where to look in the UserVar array given some TaskIndex.

Now the more complex part.
Since you can't store a 32-bit int without data loss in a float, those plugins which needed to store a 32 bit int (typically RFID readers) by splitting it into 2 ints of 16 bit.
But then people wanted to store those 32 bit ints (or even longer) into Dummy tasks and thus we needed something else.

This became quite messy, so I created a new struct which has a size of VARS_PER_TASK floats, but can also hold upto VARS_PER_TASK 32 bit ints or (VARS_PER_TASK / 2) 64 bit ints or the same amount of double values.
And to make sure it wasn't accessed directly like before I had to change the interface to the UserVar struct so people wouldn't run into not working programs but rather have the compiler fail so those who know a bit about programming would have to fix it.

Thanks i will try this.

What about the event->BaseVarIndex vs event->TaskIndex ? Which shall i use and why? If you could point me to a specific doc, it would help too

Sorry, just edited my previous reply to give more detailed info on the structures.

Thanks a lot, i will dig into it and get back here

AFAIR, I have already planned (though not started) plugin IDs for RF receive and transmit, as registered in this Github issue (P160 and P161), though I'd have to lookup the origin of those requests, as I didn't register that there. (I'm not at my private computer, where I do ESPEasy dev, ATM )

You can use those plugin IDs for this plugin. And also you should better create the PR in the main ESPEasy repository, not on the playground.

NB: We have an ESPEasy Developer starters guide here

thanks a lot to you both, i have copied something from P040 and now the value is pushed to EVENT too. I'll try to make it P160 and maybe a PR too. I'm not an expert, it will need some refactoring, but the point is, that it works now.

if you have a time, here's a working code: https://github.com/mgx0/ESPEasy/blob/rc ... 160_RF.ino

I would create a PR for this, but I don't think it's near ready. Is there anything to do before creating a PR?
Normally I would keep it for myself, but this one could be really useful for the world

please let me know. I can also hand over to someone to continue working on it. For me this is enough

Well, how to create that PR is documented in the Developer guide but you'll get some comments indeed, as it is using Serial.print() (a lot of them), and that's not used directly anymore, but should all be replaced by addLog(), and there are other issues with the code as well.

I was intending to use a library that's focused on transmitting and receiving via these modules, that also supports some different types of modules. So picking this up would probably imply a complete re-write of this plugin

I understand. Just that it works for me does not mean it can be used generally. Than I'd leave it in my public repo as a standalone plugin that could be used in EspEasy under P160.

Unfortunately I don't have enough time to do it properly

Or maybe better create a PR in playground where the old non-working P111 currently is merged.

Until a proper plugin is developed, this version could be found handy by someone

Do you at least have some info on the used devices, if for example someone does pick this up to merge into the main repo and tries to document it?

only what I have at home. I'll create a Playground PR and include the info there, okay?

here's the playground PR: https://github.com/letscontrolit/ESPEas ... d/pull/186

That plugin is essentially this code: https://github.com/sanderpleijers/EspEasy-RC-Switch

I'm aiming to use this library: https://github.com/sui77/rc-switch just have to determine what settings are needed to use it optimally.

Yes it is this code indeed. Sander Pleijers is the author of the plugin i got working today. It was not working in current version of Espeasy, it was 3 years old

rc-switch library is what is required, you're right