Service is crashing due to api limits.

[Spacelord09]

I have set up a systemd servive. For about a week it has been crashing at frequent intervals. Here is a log of such a crash:

To show the complete thing visually I made a screenshot of my Grafana dashboard:

The left side of the charts has been working as aspected for a few hours, probably because the service was not running at night. I suspect something like an API limit? Is anything more precise known about that?

[Spacelord09]

I have contacted eq3 to clarify the api limitations.
When I have more information I will post it here.

[Spacelord09]

I've got an answer from eq3:
In the first anwer they are saying It's safe to pull data every 10mins.
I then asked again for more precise values, which was answered with the comment that such a solution is not certified and therefore no support is provided.

I'll be testing the api limits myself in the next days.

I'll post the results here.

[thejockel]

Hey,
the limits for the api requested must be changed once again.
I didn't receive any data and the process crashes every time.

LG

[Spacelord09]

Hey,
the limits for the api requested must be changed once again.
I didn't receive any data and the process crashes every time.

LG

Can you provide your service's log?

[Spacelord09]

@thejockel ?

[thejockel]

@Spacelord09 sorry for the delay, didn't received the notification.

Here my Log:

2021-10-12 16:50:32 using config file './config.ini' and exposing metrics on port '8000'
2021-10-12 16:50:34 'HOME_CONTROL_ACCESS_POINT' isn't a valid option for class 'DeviceType'
2021-10-12 16:50:34 There is no class for device 'HOME_CONTROL_ACCESS_POINT' yet
2021-10-12 16:50:34 There is no class for group 'SECURITY_ZONE' yet
2021-10-12 16:50:34 There is no class for group 'SECURITY_ZONE' yet
2021-10-12 16:50:34 There is no class for functionalHome 'SECURITY_AND_ALARM' yet
2021-10-12 16:50:34 'ACCESS_CONTROL' isn't a valid option for class 'FunctionalHomeType'
2021-10-12 16:50:34 There is no class for functionalHome 'ACCESS_CONTROL' yet
2021-10-12 16:50:34 'ACCESS_CONTROLLER_CHANNEL' isn't a valid option for class 'FunctionalChannelType'
2021-10-12 16:50:34 'ACCESS_CONTROLLER_CHANNEL' isn't a valid option for class 'FunctionalChannelType'
2021-10-12 16:50:34 There is no class for functionalChannel 'ACCESS_CONTROLLER_CHANNEL' yet
2021-10-12 16:50:34 found device: room: Zimmer3, label: HOME_CONTROL_ACCESS_POINT, device_type: home_control_access_point, firmware_version: 2.2.18, last_status_update: 2021-10-12 16:46:41.113000, permanently_reachable: True
2021-10-12 16:50:34 found device: room: Zimmer3, label: Heizkörperthermostat, device_type: heating_thermostat, firmware_version: 1.0.20, last_status_update: 2021-10-12 16:01:42.018000, permanently_reachable: True
2021-10-12 16:50:34 Device of type heating
2021-10-12 16:50:34 room: Zimmer3, label: Heizkörperthermostat, temperature_actual: 22.1, temperature_setpoint: 15.0, valve_adaption_needed: False, temperature_offset 0.0, valve_position: 0.0
2021-10-12 16:50:34 found device: room: Zimmer1, label: Heizkörperthermostat TV, device_type: heating_thermostat, firmware_version: 1.0.20, last_status_update: 2021-10-12 16:06:56.559000, permanently_reachable: True
2021-10-12 16:50:34 Device of type heating
2021-10-12 16:50:34 room: Zimmer1, label: Heizkörperthermostat TV, temperature_actual: 20.4, temperature_setpoint: 13.0, valve_adaption_needed: False, temperature_offset 0.0, valve_position: 0.0
2021-10-12 16:50:34 found device: room: Zimmer1, label: Heizkörperthermostat, device_type: heating_thermostat, firmware_version: 1.0.20, last_status_update: 2021-10-12 15:38:25.900000, permanently_reachable: True
2021-10-12 16:50:34 Device of type heating
2021-10-12 16:50:34 room: Zimmer1, label: Heizkörperthermostat, temperature_actual: 20.1, temperature_setpoint: 13.0, valve_adaption_needed: False, temperature_offset 0.0, valve_position: 0.0
2021-10-12 16:50:34 found device: room: Zimmer2, label: Heizkörperthermostat, device_type: heating_thermostat, firmware_version: 1.0.20, last_status_update: 2021-10-12 16:09:06.437000, permanently_reachable: True
2021-10-12 16:50:34 Device of type heating
2021-10-12 16:50:34 room: Zimmer2, label: Heizkörperthermostat, temperature_actual: 18.4, temperature_setpoint: 10.0, valve_adaption_needed: False, temperature_offset 0.0, valve_position: 0.0
2021-10-12 16:50:34 waiting 600s before next collection cycle
Traceback (most recent call last):
  File "/mnt/./exporter.py", line 315, in <module>
    e.collect()
  File "/mnt/./exporter.py", line 279, in collect
    time.sleep(self.__collect_interval_seconds)
TypeError: 'str' object cannot be interpreted as an integer

[Spacelord09]

@thejockel You have another bug which I already fixed for myself.
@auhlig I'm going to create a PR for it.

[thejockel]

Hey :)
today I received this message on my phone.
Now all request with the exporter fails.

I reduced the calls and will keep you up to date.

[Spacelord09]

@thejockel What timeout are you using?
For me im using 300s.

[thejockel]

I am also using a timeout of 300s.

But my container was started multiple times.
This allegedly caused the many requests.

Best regards :)

[zeph]

I have 2 containers for dealing with 2 installations... I set it to 600... btw, there is an int() conversion that needs to go into the code, I pushed it to my master branch zeph@8c3911b ... we shall also consider to change the default value instead of passing a parameter here... shall we stay on the safe 600 (10min) for everyone?