search

letscontrolit / ESPEasy

Easy MultiSensor device based on ESP8266/ESP32
http://www.espeasy.com
Other
3.26k stars 2.21k forks source link

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

Open tonhuisman opened 2 years ago

tonhuisman commented 2 years ago

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:

New controllers:

Reference: ESPEasy Development guide

TD-er commented 2 years ago

I added it to the pinned issues.

handfreezer commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

And add it to the "testing E" set.

handfreezer commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

Right : and this is exactly why I:

TD-er commented 2 years ago

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 commented 2 years ago

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?

tonhuisman commented 2 years ago

Have a look at the guide for developers, new to Github and ESPEasy, part of our Read The Docs (RTD) documentation. On that same page, a few paragraphs up, there is also a guide on how to set up your development environment using VSCode and PlatformIO, as that's currently the preferred development environment.

TD-er commented 2 years ago

create a branch, and make a clean delivery commit in it?

That's the main thing you need to do. No need to fork it again. Then push the commits on this new branch and go to the Github page of the letscontrolit/ESPEasy repo (either on the pull request or the code page). There you will be presented with a yellow-ish bar asking you to create a pull request and follow those steps. If you later push new commits to that same branch, those will be appended to that pull request as you essentially link that branch to the pull request. All is explained in the link posted by Ton.

handfreezer commented 2 years ago

Hello. Sorry for being absent.i should be able to do the job on next two weeks.

20220306: I started to prepare the pull request on my fork in a branch named P130 (I can't use previous commit as they are not clean, and I created my plugin under P127 already used... :-( ). I have to clean up the code as I did tests before ending to this solution. Question : you ask me to add it to "testing E" But, I would like also to have a personnal profile build with only what I need. May I ask you how to do it without pulling it?

tonhuisman commented 2 years ago

I would like also to have a personnal profile build with only what I need. May I ask you how to do it without pulling it?

There are several ways to achieve that, the officially supported ways:

Some alternatives: (when not using a Custom.h, and assuming you use PlatformIO)

handfreezer commented 2 years ago

OK, thanks for answer. So, adding a custom personnal env in platformio_esp32_envs.ini is not the right way, isn't it?

tonhuisman commented 2 years ago

adding a custom personnal env in platformio_esp32_envs.ini is not the right way, isn't it?

Adding such environment is only feasible if it adds an improvement to ESPEasy for all to benefit. In your case it is way easier to have a local Custom.h file. You can of course create several of these, and rename to Custom.h when desired. Just remember to not include them in a PR.

handfreezer commented 2 years ago

@tonhuisman : Thanks for all your answer. Note that compiling TEST_E : I failed sometime with a memory size error, so with customer.h I success each time as keeping only controller/notif/plugin I need, it's perfect!

On my side, I have ended my first cleaning of code to do a first PR (prep on this branch), BUT I would like to document the use of this plugin (with simple schema, and picture). May I ask you where this should be done to win a bit of time?

tonhuisman commented 2 years ago

compiling TEST_E : I failed sometime with a memory size error

Are you building that using VSCode/PlatformIO? And what operating system?

I would like to document the use of this plugin

That is a great initiative šŸ‘

Documentation is part of the source code. The format used is ReStructured Text (.rst files), using the Sphinx tools. Initial setup is documented here. (Need to execute at least once). Once the PR is merged your doc work is available on the ESPEasy readthedocs page. What to do to add plugin documentation:

handfreezer commented 2 years ago

Waouh, ok, it is a lot of stuff, but I don't stop my work here, let me this week to have a look. About my environment, I'm under W10+VSCode+PlatformIO.

handfreezer commented 2 years ago

Hello, It was more complicated to start writing doc as I was thinking, but it is done, and commited on here . I feel my plugin is ready to create a PR. Maybe, do you want just to review the doc before? (I'm uploading it here) => note that I left a blank at the end for adding link to aliexpress with your referral to earn points to help the ESPEasy project.

tonhuisman commented 2 years ago

It was more complicated to start writing doc as I was thinking, but it is done

Understood, I've gone through the same learning curve, some time ago, but it is looking good, though there are a few spelling thingies to be resolved.

I feel my plugin is ready to create a PR

It sure does look like that šŸ‘ so, just create the PR, and we'll comment on it (we're always nice šŸ˜„), but that is all part of the learning curve.

handfreezer commented 2 years ago

Well, I have a problem: image I fell I'll have to solve this before to check my plugin is always working well. I'll also include an option to convert Irms value to real value.

tonhuisman commented 2 years ago

I'd not bother about that now and just create the pull request, as suggested, as that merge can be done later without much issue.

handfreezer commented 2 years ago

Pull request created, but I failed to remove some local commit on my repo from pull request like creating a custom build in general config file or adding an alert header in the readme.md file of the project to redirect people to the original project...

=> the pull request

flashmark commented 1 year ago

I am playing around with the MQ135 CO2 sensor (and MQ3 alcohol sensor) trying to combine them to a generic MQxxx sensor controlled by a table. Can you assign me a plugin ID for this attempt?

By the way, I am not sure about the quality of these sensors. Seems to deviate a lot from my MHZ19.

tonhuisman commented 1 year ago

Can you assign me a plugin ID for this attempt?

P145 is assigned, please use Gases - MQxxx (MQ135 CO2, MQ3 Alcohol) for the PLUGIN_NAME, to keep naming in line with other sensors in this category.

Brommander commented 1 year ago

I designed a few plugins for myself, which have been working well for me for about a year now. I would like to integrate this into ESP-Easy so that everyone can use it.

  1. Read out the electricity meter from the energy supplier via the optical interface
  2. Read out the inverter via Modbus (so far only Kostal have been tested)
  3. Read out a Varta Storage via Modbus
  4. I2C-Analog Output card 4 Chanel 0-10V (https://www.horter.de/blog/i2c-analog-output-4-kanaele-10-bit/)
  5. Controller that exchanges all device data with a Siemens PLC via S7 communication

Can I get a plugin ID for this? Besides, I'm starting to create documentation for it.

TD-er commented 1 year ago

I guess this is for the code in this PR: https://github.com/letscontrolit/ESPEasy/pull/4790

It looks like there is a lot of functional overlap with the P044 P1 gateway. Is that correct?

For the Modbus plugins, are they almost copy/paste implementations of the AccuEnergy plugin? Thing is that I'm working on making a more generic way to implement Modbus, so all Modbus plugins could use the same bus (if desired) and not be waiting till a reply is given. Like the SenseAir S8 is quite slow in responding (200 msec typically) and the AccuEnergy is also a bit slow. For the Eastron plugin, I already made a start to create a list of registers that need to be read and then handle them one at a time periodically polling whether a new result is in and start requesting the next one. This way there is no blocking code.

The idea is to make this a generic framework for all Modbus plugins.

The recent changes to the Eastron plugin also deals with reducing the huge amounts of strings by generating them.

I can reserve a number of plugin IDs for your plugins, but please also have a good critical look at the code to see if some of my remarks here can be applied to your plugins/code.

Brommander commented 1 year ago

Sorry for the late feedback. It took some time to look at the mentioned plugins.

The P044 P1 gateway reads the serial data and makes them available to a web server without evaluation. My plugin evaluates the data and provides them as variables in the device. Furthermore the used interface is a little bit different.

The plugin AccuEnergy uses Modbus RTU. For the inverter and Varta memory Modbus TCP is used. I did not build the plugins generically but programmed them for my use cases. I welcome the idea of a generic framework for Modbus. It is ok for me then not to publish my plugins and use them only for me until the better version is ready. I used the "old" Eastron plugin as a template to select the different registers. I will have a closer look at the last changes.

Thanks for the plugin ids. The communication with a Siemens PLC must be a controller. So that individual devices can be read / written via a selection.

tonhuisman commented 1 year ago

The P044 P1 gateway reads the serial data and makes them available to a web server without evaluation.

That's correct, but there is an open FR (and on my non-public todo-list šŸ˜‰) to add that as a feature, for all available data, and also an FR to support the Swedish variation of the protocol.

TD-er commented 1 year ago

Thanks for the plugin ids. The communication with a Siemens PLC must be a controller. So that individual devices can be read / written via a selection.

Check! I updated the start post, so you can use C020 for this.

flashmark commented 10 months ago

I would like to play with the ens160 TVOC sensor (gases). This is yeat another I2C based gas sensor. Can I reserve a plugin number for this one? ScioSense provided an Arduino library on GitHub (https://github.com/sciosense/ENS160_driver). Sensor is still traveling from ALi to home...

TD-er commented 10 months ago

There are lots of calls to delay() in that library, so please try to get rid of those as we really don't want to use delays in ESPEasy.

delay(1) is OK when needed, but not much longer.

flashmark commented 10 months ago

Thanks for the warning. Then I have to rewrite it to something more suitable for ESPEasy. Is there any convention on where to put such device specific code in ESPEasy? I see imported libraries in \lib. But if I have to rewrite stuff I assume it is better to put it all in the \src\PluginStructs\Pxxx_data_struct.cpp? For now I will use P164, I can always renumber it.

tonhuisman commented 10 months ago

Is there any convention on where to put such device specific code in ESPEasy? I see imported libraries in \lib

Usually we add the library in the lib folder, and sometimes rename it, depending on the level of changes, or if it's backward compatible, just keep the original name. It's always nice to give the improvements back to the original project, though some of the libs haven't been actively maintained for a long time or even abandoned, so feedback can be slow at times.

tonhuisman commented 10 months ago

The library has a quite peculiar way of controlling the sensor, pulling pins high and low, and also sends logging to the serial port when a variable is set. And the coding style is, well, 'different' from what's more commonly seen in Arduino libraries. I suggest to add #ifdef ENS_DEBUG / #endif around those debug statements (add a line // #define ENS_DEBUG in the .h file so it can optionally be enabled during development), as we want to keep the code as lean as possible.

mgx0 commented 8 months ago

As per P160 here's a playground plugin update: https://github.com/letscontrolit/ESPEasyPluginPlayground/pull/186

tonhuisman commented 8 months ago

As per P160 here's a playground plugin update: letscontrolit/ESPEasyPluginPlayground#186

I'll start migration soon-ish, still working on other issues and improvements šŸ˜‰

andibaciu commented 7 months ago

Hello, I designed a plugins for IKEA Vindstyrka. I would like to integrate this into ESP-Easy so that everyone can use it. With this plugin you can read next parameters from IKEA device:

Can I get a plugin ID for this?

tonhuisman commented 7 months ago

I've assigned P167 to the IKEA Vindstyrka, and hope it can be combined to also support the Sensirion SEN5x devices. Description for the device should probably be Environment - Sensirion SEN5x (IKEA Vindstyrka), assuming the base sensor is the main feature.

chemmex commented 7 months ago

@tonhuisman would it be hard to also add NOx from SEN55?

tonhuisman commented 7 months ago

@tonhuisman would it be hard to also add NOx from SEN55?

Have to look closely at the PR for P167 (there will be some feedback, as I already had a quick glance at the code šŸ˜‰), but the NOx measurement is interesting enough to be included in SEN55 mode šŸ‘

andibaciu commented 7 months ago

@tonhuisman would it be hard to also add NOx from SEN55?

After PR for P167 finish, I intend to make an update and integrate standalone SEN54 and SEN55 sensors.

flashmark commented 7 months ago

I am playing with a plugin to control the pump of my floor heating. I want local control with remote override and use a RGB led for status. This made it a bit too complex for rules. However, it is not really a standard plugin, although reusable for thermostats alike control. Question is how to handle such plugins? Is there a reserved plugin range to prevent overlap with the growing amount of plugins? I started with P999, but it looks like the plugin ID is a 8 bit integer, now using P254 locally. Looks likewe are rapidly filling the available space.

tonhuisman commented 7 months ago

We already have the ESPEasyPluginPlayground repository for a long time, but reality is that, because of many improvements to the ESPEasy Core code, and not many updates of the code on the playground, a lot of the plugins there are no longer compatible with the current ESPEasy code. And another issue is that a lot of code is written with quite basic Arduino-knowledge & skills, resulting in, well, less-optimal code, to name it nicely. I've migrated a few of the plugins there to this repo, and it's usually a lot of work adjusting to both the current code, and fixing inefficient code.

The PluginID is indeed limited to an 8 bit unsigned int (uint8_t), so 254 is a safe limit to apply.

By the gist of your explanation, it seems quite reasonable that other ESPEasy users might be interested in your plugin, so the simple solution is to assign the next available plugin ID (P168), I just need a matching description to add it to the list šŸ˜‰ The only thermostat-like plugins currently available are the Level Control (P021) and ThermoOLED (P109), so there is room for extension there.

flashmark commented 7 months ago

Thanks for feedback. P109 is too complex for my use case. But I missed P021. This looks close to my prototype, except for the LED feedback. I have to study P021 closely to estimate impact on adding my stuff or just reuse that one.

Current design:

Note I am pretty well aware of real-time software, but more involved with UML and Powerpoint than having C++ experience... So review is required. It would be nice to have a "plugin builders manual" providing references and design guides and rules. I can help with the writing of such documentation as long as I get the right feedback from the architects.

One of the questions for me is how to access IO pins. Direct Arduino function calls ere available, but I also see some ESPEasy abstraction levels. I need to do reverse engineering of existing plugins which could be potentially bad examples. A cookbook would tell me how to do this best...

flashmark commented 6 months ago

Still playing with my pump controller. Probably the name fits best as "regulator - heating pump" or "regulator - pump". Main difference with P021 is additional control to keep a pump running for a minimum time and to switch it on for s short maintenance run. An optional 3-color LED can be used to see if pump is switched on, switched off or running in maintenance mode. If this sounds as an interesting plugin to share I will add the documentation. I am thinking of ways to make it more versatile. But the main purpose is to keep my heating pump running when needed.

TD-er commented 6 months ago

Not sure if it should be 1 plugin and if it is only a minor extension to an existing plugin, why not adding such a feature to the existing plugin via some parameter or as a command? Or maybe P021 is not sending an event so maybe that's all what is needed to make it all work?

tonhuisman commented 6 months ago
  • Several control modes: (OFF, ON, STANDBY, LOCAL, REMOTE)

The OFF and ON states are clear (as described), but not sure what kind of purpose or meaning Standby, Local or Remote would have?

If the state can be changed by a command, then you have the option of remote-control, as there are several ways of sending commands to a unit, HTTP, UDP (P2P), MQTT, Time based. One factor to take care of would be long-time timers for the maintenance mode, like 2 weeks or smt. in that range, as you would want that to survive a reboot/power-cycle. And currently, P021 is one of the few plugins that can actually store a value (probably should be a separate task instance), but storing that too often will cause damage to the flash šŸ¤”

Controlling a multi-color led, either 3-color via a few GPIO pins, or a Neopixel that has a full RGB color scale, could be handled from rules, using the correct events. Adding some new events shouldn't be too hard. Currently, an event is generated when the output state changes (sendData(event)).

Controlling GPIO state can be done in the standard 'Arduino' way via digitalWrite(), or using some more low-level, but much faster, functions. Several examples can be found, even in P021.

flashmark commented 6 months ago

Thanks, good food for thoughts and helping me to understand the design patters for ESPEasy.

My initial idea was to configure the "mode" from the web interface and use an on-off command only for remote control. But that can be changed. Background: Floor heating pump with standard thermostat control. Hot water coming from heater will start the pump. When heater is switched off (low supply temperature) pump will run for a predefined time to spread remaining heat. However, the pump should run at least once a day for 5 minutes to prevent bearings will become dry and pump fails. Additional modes are OFF: Never switch it on; OF: keep it always running; STANDBY: Keep it off, but still run 5 minutes a day; REMOTE: on demand force pump on by a remote control algorithm. LED can indeed be separated as long as the internal state is made available. This makes an extension of P021 much easier. I will first finish hardware and current private plugin. Once I get everything running I will study migration to P021.