custom telegram handler

[proddy]

from @tp1de

Very long time ago I made a proposal to introduce "customizable" entities by telegram-type and offset. Maybe still an idea to support special installations and requirements.

I don't recall that, but its really good idea. We could add to the Customization page the ability to add a new Telegram to the EMS device in which you choose a name, the type (short, int), the divider (div10, div2 etc) and position. This would only be for read telegrams though.

Originally posted by @proddy in #908 (comment)

[proddy]

What do you think @MichaelDvP ?

[tp1de]

From my point of view you should decide / consider the following points:

• How to secure overall ems-esp stability and memory usage? What are the impacts of additional functions / languages on memory and cpu load? (b14 is stable b15 was not ...)
• Should this function (custom telegram handlers) be implemented in ems-esp code or in the home automation system (HA / ioBroker etc). Within ioBroker I implemented some months ago but made it hidden because it needs a lot of knowhow about telegram structure. (ioBroker adapter is used by approx. 550 people). It works for read / write on hex telegrams and even for telegram types not supported by ems-esp yet (holiday periods / switchtimes for my RC310)
• I could implement for HA too using node-red (to keep my JS code). I already implemented my km200 coding to HA including the power consumption recordings into the energy dashboard of HA.
• While implementing in home automation system I used an imbedded syslog server to analyse all telegrams from ems-esp. While using this way it would be good to add a filter within syslog function in ems-esp to reduce the number of telegrams send and therefore reducing the cpu load within home automation system.

[tp1de]

That's the way the parameters are entered in ioBroker. I used it to test the functionality:

[MichaelDvP]

Yes, i think it's possible. I see two possible ways:

1. add it to customization device. Check in EMSdevice::handle_telegram for the custom entity, process and then look for normal telegrm processing.
2. add entity extra with parameters device_id, telegram, offset, type, divider and process in EMSESP::process_telegram. This allows to process parameters from unknown devices.

[MichaelDvP]

But i'm not sure that this is really helpfull. I've tried something like this a while ago with some unknown settings/values from solar module (see

EMS-ESP32/src/devices/solar.cpp

Lines 227 to 237 in 88404bc

	/*
	// unknown values for testing and logging. Used by MichaelDvP
	register_device_value(
	DeviceValueTAG::TAG_DEVICE_DATA, &setting3_, DeviceValueType::UINT, FL_(setting3), DeviceValueUOM::NONE, MAKE_CF_CB(set_CollectorMaxTemp));
	register_device_value(
	DeviceValueTAG::TAG_DEVICE_DATA, &setting4_, DeviceValueType::UINT, FL_(setting4), DeviceValueUOM::NONE, MAKE_CF_CB(set_CollectorMinTemp));
	register_device_value(DeviceValueTAG::TAG_DEVICE_DATA, &data11_, DeviceValueType::UINT, FL_(data11), DeviceValueUOM::NONE);
	register_device_value(DeviceValueTAG::TAG_DEVICE_DATA, &data12_, DeviceValueType::UINT, FL_(data12), DeviceValueUOM::NONE);
	register_device_value(DeviceValueTAG::TAG_DEVICE_DATA, &data1_, DeviceValueType::UINT, FL_(data1), DeviceValueUOM::NONE);
	register_device_value(DeviceValueTAG::TAG_DEVICE_DATA, &data0_, DeviceValueType::UINT, FL_(data0), DeviceValueUOM::NONE);
	*/

) without success. Changing the settings have no effect and the values are used for a internal calculation for dhw correction.

I'm sure we'll see a lot of F7/F9/BE/BF telegrams watched, but very rarly a usefull value. It's more for power-users/devolpers. Maybe use only a telnet command to add such a custom handler? Or limit it to 5 entites, usefull values should be reported here and added to the core.

[tp1de]

I agree to Michael's comment. I added this function to my ioBroker adapter to store values of unknown telegrams and track changes. This was without success and I took it out. Better to observe the telegrams while changing values on thermostat or boiler.

[MichaelDvP]

@tp1de

(b14 is stable b15 was not ...)

I think i found it (or one possible cause). Please set entity-language to en or try my new dev build.

@proddy It's also in the tech branche:

EMS-ESP32/src/helpers.cpp

Line 730 in 71d22f6

if (force_en || (Helpers::count_items(strings) >= language_index + 1 && strlen(strings[language_index]))) {

has to be if (!force_en && .... With actual you get a nullptr if lang not set, but force_en (e.g. in HA mqtt).

[tp1de]

@MichaelDvP testing b15 with entity language set to en is enough?

[gwilford]

Better to observe the telegrams while changing values on thermostat or boiler.

Hey guys, the above is what I had in mind when I wrote this

[proddy]

What triggered this enhancement was this issue from @gwilford (#918 - DHW flow rate found in UBAMonitorWWPlus(0xE9) telegram). Instead of getting a flood of requests to add more data elements, we could enable the end-user to add these manually and if there was enough interest bring it into the main code. Nothing to do with nodered, km200 or scaping the syslog file (which is nasty!). I'm just collecting ideas for the future.