There are two types of errors I get often since quite some time.
1. homeassistant.helpers.device_registry.DeviceIdentifierCollisionError
It seems the Fritzbox Tools are adding the same UPnP like the UPnP integration does.
In my house the are 3 Fritz devices:
- 7530ax connected to DSL
- 7490 used as a Mesh repeater via Cable
- DVB-C used as a Mesh repeater via Cable
Error
homeassistant.helpers.device_registry.DeviceIdentifierCollisionError: Identifiers {('upnp', 'uuid:75802409-bccb-40e7-8e6c-444E6D315FAA::urn:schemas-upnp-org:device:InternetGatewayDevice:1'), ('upnp_host', '192.168.144.6')} already registered with DeviceEntry(area_id='serverschrank', config_entries={'6b5a3eeaa11b27cde5508789d87640df', '5707515fabc424595675b265f20d0549'}, configuration_url=None, connections={('upnp', 'uuid:75802409-bccb-40e7-8e6c-444E6D315FAA')}, created_at=datetime.datetime(1970, 1, 1, 0, 0, tzinfo=datetime.timezone.utc), disabled_by=None, entry_type=None, hw_version=None, id='7498662beb328dc3ce13b159ae215310', identifiers={('upnp', 'uuid:75802409-bccb-40e7-9f6c-444E6D315FAA::urn:schemas-upnp-org:device:InternetGatewayDevice:2'), ('upnp_host', '192.168.144.6')}, labels=set(), manufacturer='AVM Berlin', model='FRITZ!Box 7530 AX', model_id=None, modified_at=datetime.datetime(2024, 8, 15, 7, 16, 38, 367026, tzinfo=datetime.timezone.utc), name_by_user=None, name='fritz7530ax-box', primary_config_entry='6b5a3eeaa11b27cde5508789d87640df', serial_number=None, suggested_area=None, sw_version=None, via_device_id=None, is_new=False)
How can I get rid of the double entry?
2. Invalid timestamp in the logs (problem itself found)
ValueError: minute must be in 0..59
2024-08-17 22:58:59.992 ERROR (MainThread) [zeep.xsd.types.simple] Error during xml -> python translation
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/zeep/xsd/types/simple.py", line 79, in parse_xmlelement
return self.pythonvalue(xmlelement.text)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/zeep/xsd/types/builtins.py", line 44, in _wrapper
return func(self, re.sub(r"[\n\r\t ]", " ", value).strip())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/onvif/types.py", line 25, in pythonvalue
return super().pythonvalue(value)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/zeep/xsd/types/builtins.py", line 44, in _wrapper
return func(self, re.sub(r"[\n\r\t ]", " ", value).strip())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/zeep/xsd/types/builtins.py", line 180, in pythonvalue
return isodate.parse_datetime(value)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/isodate/isodatetime.py", line 56, in parse_datetime
tmptime = parse_time(timestring)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/isodate/isotime.py", line 131, in parse_time
return time(int(groups['hour']), int(groups['minute']),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: minute must be in 0..59
This error repeats several times, every about 2 seconds for a minute.
This is just nonsense which I get angry every time I read such a log. It started with Java to do such non-helpful stack traces, just printing the error but not the values that cause the problem.
I’d like to know:
If the value is not within 0…59 - which value is it trying to parse? Why can’t a developer print the value itself if there is something wrong with it? Is it null, is it above 59? Who called the parse_time? I have no idea which value it could be, from which config or integration. But it occurs many times in the log. How can I find out the source of the problem?
The are template sensors being called hourly using now, and I guess I see the problem. There is no weather prediction hourly for today at 23:59, so it is null. But What the Heck why can the logs not tell my the value that cause the problem? In the best case the output would be “while trying to parse the template sensor state “{{ … }}” for the sensor named “Hitze” the is the value (null) being used as a minute”
Edit: No, it occurs every hour at :59 so I guess someone adds a minute somewhere without using date functions and the invalid value could be 60, making the minute parameter invalid, but it is not me, probably met.no or whoever. I don’t see the source of the error in the logs. Neither the calling function nor the value.