Allow overriding delay_message for gateway serial communication through setting

[mkaufmann]

I have an automation that closes a lot of covers at once

2024-07-01 22:32:15.514 DEBUG (SyncWorker_39) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 1a, data 00 1a 02 08, status = 0x00> - Serialized: a55a6b07001a02080000b01a0060
2024-07-01 22:32:15.514 DEBUG (SyncWorker_1) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 23, data 00 0c 02 08, status = 0x00> - Serialized: a55a6b07000c02080000b023005b
2024-07-01 22:32:15.514 DEBUG (SyncWorker_2) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 1e, data 00 21 02 08, status = 0x00> - Serialized: a55a6b07002102080000b01e006b
2024-07-01 22:32:15.515 DEBUG (SyncWorker_2) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 2b, data 00 0c 02 08, status = 0x00> - Serialized: a55a6b07000c02080000b02b0063
2024-07-01 22:32:15.516 DEBUG (SyncWorker_41) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 1b, data 00 14 02 08, status = 0x00> - Serialized: a55a6b07001402080000b01b005b
2024-07-01 22:32:15.516 DEBUG (SyncWorker_41) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 27, data 00 0c 02 08, status = 0x00> - Serialized: a55a6b07000c02080000b027005f
2024-07-01 22:32:15.516 DEBUG (SyncWorker_41) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 28, data 00 1a 02 08, status = 0x00> - Serialized: a55a6b07001a02080000b028006e
2024-07-01 22:32:15.516 DEBUG (SyncWorker_41) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 19, data 00 19 02 08, status = 0x00> - Serialized: a55a6b07001902080000b019005e
2024-07-01 22:32:15.517 DEBUG (SyncWorker_42) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 20, data 00 0c 02 08, status = 0x00> - Serialized: a55a6b07000c02080000b0200058
2024-07-01 22:32:15.517 DEBUG (SyncWorker_42) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 29, data 00 22 02 08, status = 0x00> - Serialized: a55a6b07002202080000b0290077
2024-07-01 22:32:15.518 DEBUG (SyncWorker_43) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 1c, data 00 3d 02 08, status = 0x00> - Serialized: a55a6b07003d02080000b01c0085
2024-07-01 22:32:15.518 DEBUG (SyncWorker_43) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 24, data 00 1a 02 08, status = 0x00> - Serialized: a55a6b07001a02080000b024006a

Not all of them move reliably though. I don't understand the true root cause but would love to play around with delay_message to see if it helps.

Also as a small nit: It seems that the logger is not forwarded to the serial constructor (looked at esp2) and I suspect that's the reason why I dont see the serial messages themselves. Is that intentional?

[grimmpp]

There are different baud rates FAM has e.g. 57600 and internally the bus has 9600. If you send too many messages at once the internal buffer of FAM will overflow and messages get lost. That's the reason for the delay messages.

Of course, I can create a configuration parameter for it.

Maybe it could make sense to create something like a scene for covers. This could be a cover in HA which you can use to synchronously control many covers. What do you think.

What you can do already now is to create a button triggering an automation which es closes or opens all covers.

[mkaufmann]

What you can do already now is to create a button triggering an automation which es closes or opens all covers.

For open I could have one EnOcean command control multiple covers at once and thus wouldn't get overflow. I agree this should work. For close it's a little bit more complicated as I don't want to close the covers completely but instead have the position on each cover in a way that only the "slits" are still open and thus I still get a little bit of environmental light. To my understanding I couldn't accomplish that using one EnOcean telegram. (This is also why the 100ms cover resolution was useful to me)

If you send too many messages at once the internal buffer of FAM will overflow and messages get lost. That's the reason for the delay messages.

That's what I fear. I want to use the parameter to throttle the events even more.

[grimmpp]

Added message_delay as config parameter into feature-branch.

Please, let me know what value fits best for you. Actually the default value 0.01 should allow about 40 telegrams at the same time.

[mkaufmann]

This line

message_delay = gateway_config.get(gateway_config[CONF_GATEWAY_MESSAGE_DELAY], None)

looks like it should be

message_delay = gateway_config.get(gateway_config[CONF_GATEWAY_MESSAGE_DELAY], 0.01)

I was getting

2024-07-08 22:24:27.367 ERROR (Thread-4) [root] Uncaught thread exception
Traceback (most recent call last):
File "/usr/local/lib/python3.12/threading.py", line 1073, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.12/site-packages/eltakobus/serial.py", line 158, in run
time.sleep(self.delay_message)
File "/usr/src/homeassistant/homeassistant/util/loop.py", line 131, in protected_loop_func
return func(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object cannot be interpreted as an integer

and with the suggested change thats fixed

[grimmpp]

Hello @mkaufmann,

Sorry! Actually gateway_config[ was too much. The default value is set in the schema and at this point it should never be None.

I changed it now on feature-branch and tested it again. For me both default value and adding the parameter in the config works now. I've also added the value to the Gateway Devices so that you can see what is taken.