custom variables

[proddy]

From a discussion with Michael:

The scheduler have entity/command to activate/deactivate the schedule. This was for replace the forceheatingoff, sending selflowtemp 0 every minute to stop the boiler, and disable scheduler to activate the boiler again.
Maybe it's a nice addition to also manipulate the schedule command value via command. But difficult to add in the command structure.

I wonder if we can add custom RAM entities only stored in ems-esp and use them for setting a variable value. E.g. in custom use devcie/telegram type 0x0 for storing 256 bytes. Custom entity: myseltemp, device 0, type 0, offset 0, UINT, Scheduler: every minute, command: boiler/seltemp, value: custom/myseltemp. Then the flowtemp can be set via mqtt: custom/myseltemp and is used by the scheduler.

Originally posted by @MichaelDvP in #1418 (comment)

[proddy]

I see, That's quite clever. How about instead of using custom entities to store variables we could create a new type called Variables. Maybe limit to 10 max, as strings with a default value that is stored in LittleFS and loaded at boot.

[proddy]

Something like:

• In the Custom Entity web page you can choose to read/write the value from EMS (with a deviceID, typeID, Offset) or as a Variable with default value. It means extending Custom Entity to include a Custom Entity type, and it's persisted in the FS. The value could be written to NVS or just kept in memory (which means loosing after a reboot)
• Add a new API call to read or write a value to the Custom Entity
• Modify the Scheduler to also accept a Custom Entity as a value, instead of a hardcoded value

@MichaelDvP thoughts?

[MichaelDvP]

Comments to:

1. Custom variable only with name and default value. The value can be stored as string (no need to set the type), the command-values are always processed as char*. Default value should be stored in FS, changing the value by API should only use RAM (to avoid wear of FS). Setting new default only va web page.
2. API command is already implemented for custom values (call custom <name> <value>, /api/custom/<name> {"value":"<value>"})
3. The scheduler already accepts commands (that return a value) as value. e.g. boiler/flowtemp/value returns the actual flowtemp can be processed as value parameter.

[proddy]

excellent, so we only need to implement #1 !

[proddy]

@MichaelDvP my idea with Variables was to be able to use them in Values

For example if I created a custom entity called 'foo' I could use this in the Scheduler as a value like {foo}, so its dynamic/variable and not static/hardcoded.

[MichaelDvP]

The value is in ram and can be accessed. The typical example to set the boiler flowtemp without thermostat.
Setting boiler/selflowtemp resets after 1minute, so the user has to repeat it often. We can do this with scheduler, but need a dynamic value in scheduler. Steps are now:

• create custom entityas RAM value selflowtemp
• create scheduler with timer 1 minute for command boiler/selflowtemp, value: custom/selflowtemp/value
  Now you can use the single command (API/mqtt/console) custom/selflowtemp with new value 40 and this is repeated by the scheduler every minute.

[proddy]

I didn't realize that, I need to look at the code again. I thought WebSchedulerService::command() just called the command. But cool!

[proddy]

tested, works great. I'll add some notes to the doc.