Espurna controller suggestion

[zafrirron]

More food for thoughts...

As more sensors added to espurna, it looks like espurna is getting much more than a simple wifi relay with a power meter option.... So it may got to the point of adding a controller option: allow sensor(s) to be attached to relays, trigger relay(s) based on sensor value(s). adding a PID controller option will enable creating a real life relay based controller. So different sensors could activate and control different units (heaters, solenoid based utils, pumps, warning systems...). This may be not within the original espurna scope, but as I'm getting more and more attached to the esurna concept and design, it may be a valid future enhancement option.

I'm ready to develop this, based on feedbacks....

[icevoodoo]

second that... something asked by me and others in here https://github.com/xoseperez/espurna/issues/591 need this for making sonoff TH10 and TH16 to work independent (like a cronothermostat).

[gn0st1c]

i've also been thinking about this for a while now. first as a simple rule engine, or more like clips or soar..

we already have "(if) button1 (is pressed then) relay1" but via configuration. and the scheduler.

what i have in mind is;

• mode: day, night, user at home, user away etc. (day, night by NTP, user presense by external triggers)
• actions: set of actions to execute
• conditions: set of conditions to feed triggers
• triggers: a trigger to execute actions

e.g.: action_relay1on: RELAY1 on, LED1 on action_relay1off: RELAY1 off, LED1 off

action_relay2on: RELAY2 on, LED2 on action_relay2off: RELAY2 off, LED2 off

condition_1: if MODE is DAY condition_2: if MODE is NIGHT condition_3: if SENSOR1 > 40

trigger_1: if [condition_1] [action_relay1on] trigger_2: if [condition_2] [action_relay1off, action_relay2on] trigger_3: if [conditon_1 && condition_3] [action_relay2off]

also security/failsafes. i mean what to do if we can't read a sensor or can't get date from ntp. e.g.: if MODE is DAY and ntp failed so the system is not able to update the MODE. should the triggers continue to work with stuck values?

suggestions welcome..

[icevoodoo]

also security/failsafes. i mean what to do if we can't read a sensor or can't get date from ntp. e.g.: if MODE is DAY and ntp failed so the system is not able to update the MODE. should the triggers continue to work with stuck values?

I think is not so hard. It must be a general safety rule and in case of ntp or senzor timeout (user choice here in minutes) we must trigger a default action like relay off.

Example: You control a boiler and relay is on. In mean time you loose ntp or temperature senzor is not responding, In that case I will chose my default safety rule to cut relay off.

[gn0st1c]

also i can't decide if a "script language" is better then "action/condition/trigger". i have already written several compilers and interpreters for embedded stuff in my life time so, i won't mind writing another tiny one.

maybe with a round robin scheduling running separate from espurna's main loop callbacks. maybe i should just code something and try :)

[zafrirron]

Thanks @icevoodoo @gn0st1c, for your responses...and support of this discussion...

Looking at other home automation systems, it looks like the scripting (or conditional triggering by external events) is well supported by other systems (stringify, home assistance ....) they could easily support espurna based systems via the http api (like done for many other systems...).

My original thought was based on a possible need for local "controller type" actions, usually done by controller systems as onboard embedded function (independent of external systems, latency...), i.e like thermostat model controller, tight coupling of a sensor to actuator (relay...) to control the output result (like temperature...) in a closed loop (real time) control function.

Personally I would separate the "controller" function from rules/scripts engine functions, as it looks like espurna firmware original design architecture was for embedded modules, I would try to keep it this way (yes the additions of integrating/reporting to external systems and http/mqtt apis is great for itegrations of local modules), but I would try to avoid pushing "Automation Hub" functionality into every board since very quickly you will get needs for automating more that single entity ...this is exactly why these hubs work that way.

[icevoodoo]

I think a device must have 3 functionalities:

1. Interrogation and reporting function for status and log purpose;
2. master-slave function (I send a command and device will execute);
3. Routine or automated tasks (I send a set of rules and device will execute in loop).

This 3 functionalities will cover a lot of people’s needs. Maybe I the near future the size of memory will increase and will see a lot of nice things embedded in a device.

[gn0st1c]

last night, as a PoC, i developed espurna scripting. supports; for/next, if/then, print, goto supports; labels and 5 different variables supports; gpio read/write todo dynamic sensor read (based on which sensor is enabled)

in it's current state, it works. (no web ui)

[icevoodoo]

Nice I wait for this to be implemented in future versions. I have seen some discussions regarding plugins. This can be implemented as a plugin?

[zafrirron]

Sure,

I just uploaded a new page and plugin template files, including documentation to allow easy plugin integration . See https://github.com/xoseperez/espurna/wiki/3rd-Party-Plugins for more details

[xoseperez]

Amazing guys.

Scripting can add a lot of power, even remove certain configuration-based rules at the moment (you could defined buttons, relays, leds... and use scripting rules to link actions between them). But I'm worried a lot of people might find it too complicated.

Maybe and option is to create a frontend for the scripting machine using an if-this-then-that approach based on selectors.

[zafrirron]

Ok,

I get the majority vote, this discussion started from PID controller integration....(I guess it should move a plugin work...) and the need is scripting model and easy rule base engine. (I'm looking into this...). The only point worth mentioning (again) here is that most IOT external controllers already have extensive rule engines, that include lots of external inputs (weather, stock rates, sun set/rise, read from news, ...) these are out of the board scope but very soon will be asked for (true they will be directed to plugins development) however lots of effort will be done were any MQTT (fully supported by espurna) could be easily integrated to any external rule engine. The current single "rule" already exist is scheduler, so first thing I believe is adding sensor magnitude based condition (if sensor x >,<,...) activate relay (with possible scheduling option). The "plugin" model for this would be adding a action hook after sensor read (or filter), registering to the hook and handle the logic in the plugin code (no core changes needed after adding the action hook).

My thought is to write a plugin that include the common trigger/action/timing model as follows:

1. Triggers - Predefined list:

   • Sensor: sensor_x above, below value
   • Relay: relay_x changed,on, off
   • Command: any registered command issued
   • Time: has reached

2. Actions:

   • Run any internal existing command (ebedis registered)

3. Delay options:

   • Use existing scheduling options

thoughts?

[xoseperez]

@zafrirron I agree with you. My first approach is always moving the logic outside the device. I use Node-RED for that. That's why this has not been implemented before. And it is not a priority.

[zafrirron]

Ok, Thanks... So back to my original thought, PID controller is definitely a device level control loop. Have you got any previous asks/references to it? See https://github.com/br3ttb/Arduino-PID-Library

The example of simple relay output may be relevant to espurna case since device usage of measuring on sensor and need to set relay to control measurement is the basic controller function. Any modern controller uses some sort of PID control loop, to get good stabilization of output result. Simple to implement (again this should be plugin dev unless you got specific queries and will make a difference on the core feature list).

[gn0st1c]

i've already developed 2.5 (2 working, one left unfinished) scripting support. i was planning to make the web ui this weekend.

1) almost a full basic language. 2) simple lexer but should be enough for everyone.

i like the simple version better as it uses less space and less cpu time and runs line by line in a while loop, so yield is possible.

        while (retcode == LINE_DONE) {          // run until SCRIPT_END
                retcode = run();
        }

e.g. code:

A = MAGNITUDE_TEMPERATURE
IF A < 25 THEN END
GPIO#5 = HIGH

[uberflyx]

I think having an onboard PID (or just bang bang type thermostat) controller will be very useful. For example, using a device running a heater, hot tub, geyser, etc. is a pretty common task and having to go via node-red (which is what I currently do too) is not safe. If the wireless loses connection I would like my jacuzzi to still reach the setpoint and not boil / freeze, for instance.

I think to keep it simple, it could take one input from any existing sensor, one setpoint and then P, I and D parameters. The output would then be a relay and I suppose would just need a threshold for on and off, probably with some hysteresis. The UI would simply ask for these values and should provide hints as to suitable PID values for a simple thermostat. Power users who are brewing beer based on specific gravity can figure out their own PID values ;) that said, I can't really imagine a case where a simple thermostat style controller wouldn't work perfectly instead of PID...

I don't think that will be too hard to implement although I haven't internalized the espurna architecture enough to do it myself at the moment.

[zafrirron]

Agree regarding external control, controller is totally internal device function.

to start with If the hook system I suggested (in pull request) will fly, a simple hook (pre and post already exists in sensor code) registration will enable the PID sensor value read... (Relay activation is the easy part...) We just need to take care of the delays (of sensor reads and relay delays) it would affect the performance but PID will get you to the optimal point anyway.

for configuration:

1. Sesor selection
2. Relay selection
3. P,I,D settings (changeable) - agree with recommended values these should be added over time to each relevant sensor
4. setpoint (changeable)

the beauty about PID, you don't need the threshold values (bang bang is close to have the "D" setting only without "P" and "I")...

I'm using the library https://github.com/br3ttb/Arduino-PID-Library for some time on esp32 and it works fine.

[nkerezov]

xoseperez: "Maybe and option is to create a frontend for the scripting machine using an if-this-then-that approach based on selectors."

Exactly ! People like me cannot go thru atom, programming and so on. .bin files are working as breeze for me. Selector kind of programming will make my life 100% easier. As know what I want ,Im quiet good with the soldering ,but I suck on atom ( just not enough time to learn).So far espurna firmware is the door for the automation for me and I higly respect all of you guys efforts ,especially xoseperez! Cheers everyone !

[mcspr]

@gn0st1c 👍 I am also hoping this system can cover current "time" cases - scheduler and pulse. FYI, ESPEasy implements tasks system for similar use case: https://www.letscontrolit.com/wiki/index.php/Tutorial_Rules - basics on how they are written https://github.com/letscontrolit/ESPEasy/search?utf8=%E2%9C%93&q=rulesProcessing&type= - wiring of events

[nkerezov]

ESPeasy implement the tasks as we need , but it is not stable. If it disconects from the brocker acts inadequat .

[Valcob]

@xoseperez What would be the best way to persist the rules that can be as simple as when button 0 pressed then relay 0 toggle and a bit more complicated like when with debounce of 50 ms if (ntp time is above 7PM and ntp time is below 6AM) then display set night mode. I could persist them as json strings in settings and do whatever I want in setup-configure step but that would bloat up the EEPROM with many unnecessary bytes for each rule. On the other hand storing them the way you did for scheduler is not so easy to do due to the possible ANDs, ORs and general tree look of the rule.

[xoseperez]

Yes, I have also been thinking about that. I'm not sure how to store the rules yet. Current settings work great for simple values or one-dimension arrays (using the setting# pattern), but we need a way to define more complex structures.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[skarcha]

Hi! Are there news about this? I'm working in my first project with ESP32 and my own device to control an air conditioner and grilles.

I'd like to use ESPurna because all the hard work is done (thanks @xoseperez !), but I need two things:

1. ESP32 support.

Any news about this? Anyone working on this?

2. A way to define rules to open and close grilles.

I could do it using Node-RED, but I'd like to have as less external dependencies as possible.

Thanks guys for your time and your work!

[Valcob]

Hi @skarcha can you please give some examples of rules that you would like/plan to use?

[skarcha]

Well, I need something like:

IF CURRENT_TEMP1 > USER_SET_TEMP1 THEN
    OPEN GRILLE1
ELSE
    CLOSE GRILLE1
END IF

"Grilles" devices are DC motors, so a time needed to open/close it should be defined.

Other command could be:

TURN OFF AC1

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue will be auto-closed because there hasn't been any activity for two months. Feel free to open a new one if you still experience this problem.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[eschava]

Guys, you can check my pull request https://github.com/xoseperez/espurna/pull/1521 as a proof of concept for feature discussed here

[Valcob]

It's coming guys but god I need more time to spend to polish it, the UI is still not perfect and espurna is only a hobby (wish I could spend 24/7 on these things though)

[icevoodoo]

Seems like a promising feature, and it is what I want to see in espurna firmware. 10x for your effort

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[knopserl]

hey guys, I'm also looking for any base for a thermostat. I did one with an OLED display using MySensors, but now I'm looking for something with an ESP (preferable with ESP32 but ESP8266 is also ok). This thread looks promising, but it seem that it has been stalled because everybody is busy. So I'm considering what is the better starting point: ESPurna or Tasmota ;-)