[Plugins] List of planned new plugins (request a Plugin-ID here)

[tonhuisman]

As it is sometimes quite hard to find the next available Plugin-ID for a new plugin, this list is supposed to be updated by either me or TD-er once a plugin is planned.
If you are working on a new plugin (for the mega branch, not the ESPEasyPluginPlayground repository, that has its own numbers), you can request a Plugin-ID to be reserved, just add a comment, a short description/title for the plugin and we'll assign an available ID.
Once the plugin is merged it must be removed from this list, as the current list of plugins is available in this Read The Docs page

New plugins, currently being worked on:

• P130 Current - IRMS_ADS1015 ( @handfreezer see ) PR [P130] Add simple circuit to get a current sensor , result is Irms #4009
• P136 Display - SSD1306/SH1106 using AdaGFX helper ( @tonhuisman) PR #(todo)
• P149 Display - ePaper 1.9" 91 segment display ( @tonhuisman) PR #(todo)
• P155 SML smart meter ( @Brommander PR pending )
• P156 Kostal PV inverter ( @Brommander PR pending )
• P157 Varta Storage ( @Brommander PR pending )
• P158 I2C analog 4ch 0-10V ( @Brommander PR pending )
• P160 RF Receiver (433 MHz) ( @tonhuisman) PR #(todo)
• P161 RF Transmitter (433 MHz) ( @tonhuisman) PR #(todo)
• P171 RFID - WL-134 (request) ( @tonhuisman) PR #(todo)
• P174 Generic - CAN Importer ( @bclbruno) PR CAN bus implementation #5120
• P179 Communication - JIKONG JKBMS RS485 Reader ( @tonhuisman) PR #(todo)
• P181 Generic SPI Interface plugin ( @tonhuisman) PR #(todo)
• P182 Presence - HLK-LD2451 Radar speed sensor (forum thread) ( @thomastech) PR #(todo)
• P183 Communication - Modbus RTU plugin ( @flashmark) PR P183 modbus RTU #5390
• P184 Switch - Triac ( @thalesmaoa) PR Feature: Add Triac Phase Control Plugin (_P184_Triac.ino) #5426
• P185 Available

New controllers: (Supported Controllers)

• C020 Siemens PLC S7 ( @Brommander PR pending )
• C021 LoRa (bidirectional communication) ( Warrick (forum link) PR pending )
• C022 CAN Controller ( @bclbruno) PR CAN bus implementation #5120
• C023 Dragino LA66 LoRaWAN ( @TD-er ) PR [WiFi] Cleanup code, split ESP32/ESP8266 specific #5149
• C024 Available

New notifications: (Supported Notifications)

• N003 Email Advanced (request) ( ?) PR #(todo)
• N004 Available

Reference: ESPEasy Development guide

[TD-er]

I added it to the pinned issues.

[handfreezer]

Hello,
I would like to get a plugin number to pull request a plugin : it is intended to measure current through classic SCT013 with and ADS1015, using RMS method.
It is already working based on Arduino pure project, then I forked ESPEasy on my github (I created a P127 plugin for local dev) and convert to a plugin. It is working well too. So I just need a plugin number I guess?

Best regards.

[tonhuisman]

it is intended to measure current through classic SCT013 with and ADS1015, using RMS method.

Isn't that already supported by Plugin 25 ADS1115 (not fully compatible with ADS1015) or the ADS1015 plugin from PluginPlayground? Or is it an extension/improvement of that plugin?
Ideally it should be as generic as possible, so it is also usable for other purposes.

P130 is the next available Plugin ID.

[TD-er]

And add it to the "testing E" set.

[handfreezer]

Hello,
None of us. All the important thing is : "Measure of Current by RMS method" : the fact is to measure the current of a sinus form, and the RMS method require to sample a lot of time in only ONE wave . Say about 50Hz, this means you have to do a lot of adc conversion in only 20ms ! From what I understood from both plugin you suggested, it is not possible.
Note I also added few parameters to do the job right like the availibility to enter the frequency, the number of wave to sample, ...
I based my work on P025 (for structure code), but I had to rework about all the job:
my local dev P127_data_struct.cpp
my local dev P127_data_struct.h
my local dev _P127_IRMS_ADS1015.ino

Remark, I still have to do an improvement : I want to add a setup key to choose sample rate and a "just-in-time reader" in continuous mode sampling.

I don't want to duplicate an already code existing if so. I just suggest my work .

[handfreezer]

And add it to the "testing E" set.

OK
Note : I can't change the first message to inform P130 is in use. May I start a specific thread for this job?

[TD-er]

OK, so it is indeed some different approach.
Have not yet looked at your code, but I will as soon as it appears as a PR. (I will add your nr to the post here)
Just one thought... is it blocking code for longer than a single period?

[handfreezer]

Just one thought... is it blocking code for longer than a single period?

Right : and this is exactly why I:

• added a warning in the setup page of the device,
• I didn't notice any bad effect on 100ms, and as I said, only 40ms is enough (in continuous reading sample mode, only 20ms seems enough),
• also, the final user can choose the comportment by changing in setup page the frequency of the wave AND the number of wave to use for sampling,
• and the measure of the current do not need a high frequency of reading, which means, the interval could be set to something like 30s or 60s

[TD-er]

I can imagine that 20 msec isn't "stable" as you may just start on the "spike" of current on devices with poor power factor.
Then it becomes quite timing critical whether you may include this spike one time or twice. Also the net frequency isn't always constant.
I guess measuring for 30 msec would also be OK and then you need to look for the zero-crossings and measure in between. Just consider that it might need to "loop" on the sample buffer, or actively wait for the zero crossing and then start to accumulate the samples until you saw 2 more zero-crossings (make sure to include a timeout)

Upto roughly 100 msec is OK, but less is better as every blocking code for over 10 msec can lead to missing WiFi packets.
I do highlight the parts in the timing stats for > 100 msec as those are the ones to look at first when running into issues.

But these kinds of discussions are best for the actual PR I guess :)

[handfreezer]

In fact, I wrote my own ino code at beginning (wifimanager + adafruit GFX + adafruit1X15 + MQTT + personnal code), and it was working for 4 months . I decided to switch to easyesp to avoid me managing the Wifi and the MQTT diffusion.
About the timing, from my understand of current RootMeanSquare formula : the most important is to get a half or a full sinus over and under zero, and the formula do the job. So, for a 50Hz voltage, you have to choose a factor of 10ms.

Note/question : I'm not used to pull-request (well, in fact, it will be my first time). I commited on mega branch on my fork of espeasy, but i commited also dirty code before the good one. is it possible to choose only good commit? or may I have to refork a new time, create a branch, and make a clean delivery commit in it?