Ebusd init error

[dkuschmierz]

Home Assistant release with the issue:

Last working Home Assistant release (if known):

Operating environment (Hass.io/Docker/Windows/etc.):

Component/platform:

Ebusd

Description of problem:

Cannot query data from circuits other then 700. Is the '700' in line 35 of init.py correct? I think there should be a reference to the configured circuit, or?

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

[fabaff]

@CrazYoshi, could you please take a look?

[CrazYoshi]

Which is your circuit? At the moment in the consts.py only 700, bai and ehp are supported.

[dkuschmierz]

I have an ehp configured the following way:

ebusd: host: 127.0.0.1 circuit: 'ehp' monitored_conditions:

• 'OutsideTemp'

Is the '700' in line 35 of init.py correct? In my opinion the configured circuit should appear here and not the fixed 700, or?

[CrazYoshi]

You're right. It should be the circuit you configured in your configuration, in your case ehp.

[dkuschmierz]

Ok, i tried to fix it by replacing '700' by CONF_CIRCUIT, and conf(CONF_CIRCUIT) to get the circuit from the configuration, but both did not work. If i replace '700' by 'ehp' it is working.

Another problem i'm facing is, that i can not overwrite the const.py with my own file. I tried to put my own file in custom_components/ebusd/const.py and in custom_components/components/ebusd/const.py, but they were not recognized.

And finally I have a question to the update logic. I see that there is a minimum time to wait of 15s. But if I restart my HA, it takes up to 15 Minutes until I have all configured values. How are the values updated? Are they all running in parallel and after 15s they try to update their values? And if yes, how are concurrent queries handled? Is that possible with ebusd? I think it's a socket connection and only one connection is possible at a time, or? How is the behavior if the sensor failed querying the value, does it skip this interval and tries it the next time, or does it query until it gets a response?

[CrazYoshi]

Ok, i tried to fix it by replacing '700' by CONF_CIRCUIT, and conf(CONF_CIRCUIT) to get the circuit from the configuration, but both did not work. If i replace '700' by 'ehp' it is working.

Yes, I had tried the same but I don't know how to handle that dynamically. Any suggestion @fabaff ?

Another problem i'm facing is, that i can not overwrite the const.py with my own file. I tried to put my own file in custom_components/ebusd/const.py and in custom_components/components/ebusd/const.py, but they were not recognized. My structure in custom_components folder is:

• ebusd
• const.py init.py sensor.py services.yaml strings.json And finally I have a question to the update logic. I see that there is a minimum time to wait of 15s. But if I restart my HA, it takes up to 15 Minutes until I have all configured values. How are the values updated? Are they all running in parallel and after 15s they try to update their values? And if yes, how are concurrent queries handled? Is that possible with ebusd? I think it's a socket connection and only one connection is possible at a time, or? How is the behavior if the sensor failed querying the value, does it skip this interval and tries it the next time, or does it query until it gets a response?

The issue here is that ebus seems to accept multiple request at the same time, if you do that only the first one more or less will succeed. To avoid this behaviour I refresh every entity every 15 seconds in this way ebus will reply correctly most of the time. I will check if there is any improvement on ebusd to request a list of entities all at once and if not maybe request a change.

[dkuschmierz]

Ah ok, i only saved the const.py and Not the whole component. Is this necessary?

Another suggestion for the update problem. Would it be possible to change the minimum update interval for each sensor and not for the complete component? Then it would be possible to vary the times to improve the behaviour...

[CrazYoshi]

Ah ok, i only saved the const.py and Not the whole component. Is this necessary?

Yes, it is necessary

Another suggestion for the update problem. Would it be possible to change the minimum update interval for each sensor and not for the complete component? Then it would be possible to vary the times to improve the behaviour...

I think this must be constant over all sensors, but I/you can ask confirmation to other people on this forum

[dkuschmierz]

Ok, i played a little bit around. What i did was, to add a logging of the communication result after the try statement in line 85. With that, i should get an log-entry every time the sensor tries to query data, whether it was successful or not.

This was the result:

cat home-assistant.log | grep "Ebus communication result"
2019-02-27 13:58:32 DEBUG (Thread-17) [custom_components.ebusd] Ebus communication result 30.50
2019-02-27 13:59:03 DEBUG (Thread-9) [custom_components.ebusd] Ebus communication result 11359.0
2019-02-27 13:59:34 DEBUG (Thread-14) [custom_components.ebusd] Ebus communication result 0.0
2019-02-27 14:00:05 DEBUG (Thread-4) [custom_components.ebusd] Ebus communication result 1.567
2019-02-27 14:00:36 DEBUG (Thread-12) [custom_components.ebusd] Ebus communication result 30.62
2019-02-27 14:01:07 DEBUG (Thread-20) [custom_components.ebusd] Ebus communication result 6443.0
2019-02-27 14:01:38 DEBUG (Thread-6) [custom_components.ebusd] Ebus communication result 12783.0
2019-02-27 14:02:09 DEBUG (Thread-5) [custom_components.ebusd] Ebus communication result 11359.0
2019-02-27 14:02:40 DEBUG (Thread-18) [custom_components.ebusd] Ebus communication result 45.94
2019-02-27 14:03:11 DEBUG (Thread-20) [custom_components.ebusd] Ebus communication result 6443.0
2019-02-27 14:03:42 DEBUG (Thread-19) [custom_components.ebusd] Ebus communication result 19832.0
2019-02-27 14:04:13 DEBUG (Thread-13) [custom_components.ebusd] Ebus communication result 1.465
2019-02-27 14:04:44 DEBUG (Thread-15) [custom_components.ebusd] Ebus communication result 6443.0
2019-02-27 14:05:15 DEBUG (Thread-12) [custom_components.ebusd] Ebus communication result 29.44
2019-02-27 14:05:46 DEBUG (Thread-11) [custom_components.ebusd] Ebus communication result 45.12
2019-02-27 14:06:17 DEBUG (Thread-2) [custom_components.ebusd] Ebus communication result 1.567
2019-02-27 14:06:48 DEBUG (Thread-6) [custom_components.ebusd] Ebus communication result 0.0
2019-02-27 14:07:19 DEBUG (Thread-17) [custom_components.ebusd] Ebus communication result 4.699
2019-02-27 14:07:50 DEBUG (Thread-18) [custom_components.ebusd] Ebus communication result 29.38
2019-02-27 14:08:21 DEBUG (Thread-21) [custom_components.ebusd] Ebus communication result 1.465
2019-02-27 14:08:52 DEBUG (Thread-6) [custom_components.ebusd] Ebus communication result 8.1
2019-02-27 14:09:23 DEBUG (Thread-14) [custom_components.ebusd] Ebus communication result off
2019-02-27 14:09:54 DEBUG (Thread-20) [custom_components.ebusd] Ebus communication result 50.44
2019-02-27 14:10:25 DEBUG (Thread-13) [custom_components.ebusd] Ebus communication result 13.00
2019-02-27 14:10:56 DEBUG (Thread-2) [custom_components.ebusd] Ebus communication result 7.0
2019-02-27 14:11:27 DEBUG (Thread-5) [custom_components.ebusd] Ebus communication result 23.81
2019-02-27 14:11:58 DEBUG (Thread-20) [custom_components.ebusd] Ebus communication result 52.94
2019-02-27 14:12:29 DEBUG (Thread-11) [custom_components.ebusd] Ebus communication result 19832.0
2019-02-27 14:13:00 DEBUG (Thread-4) [custom_components.ebusd] Ebus communication result 11359.0
2019-02-27 14:13:31 DEBUG (Thread-2) [custom_components.ebusd] Ebus communication result 29.38
2019-02-27 14:14:02 DEBUG (Thread-17) [custom_components.ebusd] Ebus communication result 0.0
2019-02-27 14:14:33 DEBUG (Thread-9) [custom_components.ebusd] Ebus communication result 1.465
2019-02-27 14:15:04 DEBUG (Thread-13) [custom_components.ebusd] Ebus communication result 88.25
2019-02-27 14:15:35 DEBUG (Thread-4) [custom_components.ebusd] Ebus communication result 12759.0
2019-02-27 14:16:06 DEBUG (Thread-15) [custom_components.ebusd] Ebus communication result 25.493
2019-02-27 14:16:37 DEBUG (Thread-6) [custom_components.ebusd] Ebus communication result 15.38
2019-02-27 14:17:08 DEBUG (Thread-18) [custom_components.ebusd] Ebus communication result 1.453
2019-02-27 14:17:39 DEBUG (Thread-9) [custom_components.ebusd] Ebus communication result 25.493
2019-02-27 14:18:10 DEBUG (Thread-21) [custom_components.ebusd] Ebus communication result 23.81

What I notice is, that i have no error entries for maybe a blocked port or something and that the time between the queries is not 15s. What exactly does the @Throttle? After reading the documentation, i think this is only to prevent queries in a faster interval than 15s, but it not ensures that the values are polled every 15s, or?

[dkuschmierz]

@fabaff Can you please have a look if it is possible to dynamically set the circuit which is used to check the monitored_conditions list in the voluptuous schema?

[danielkucera]

@CrazYoshi , can you review my patch?

[CrazYoshi]

@CrazYoshi , can you review my patch?

It seems fine to me. Good job