Closed apbarratt closed 1 year ago
Prior to this error, I'd attempted deleting the entity for last warning to see if it would come back. I've now reloaded the integration and the entity has indeed returned, but I have more errors:
Logger: homeassistant
Source: components/sensor/__init__.py:532
First occurred: 12:16:44 (1 occurrences)
Last logged: 12:16:44
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 521, in state
if value.tzinfo is None:
^^^^^^^^^^^^
AttributeError: 'str' object has no attribute 'tzinfo'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 970, in _async_registry_updated
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 590, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 654, in _async_write_ha_state
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 596, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 532, in state
raise ValueError(
ValueError: Invalid datetime: sensor.bike_last_warning has timestamp device class but provides state unknown:<class 'str'> resulting in ''str' object has no attribute 'tzinfo''
and an almost identical one:
Logger: homeassistant.components.sensor
Source: components/sensor/__init__.py:532
Integration: Sensor (documentation, issues)
First occurred: 12:16:44 (2 occurrences)
Last logged: 12:16:44
Error adding entities for domain sensor with platform super_soco_custom
Error while setting up super_soco_custom platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 521, in state
if value.tzinfo is None:
^^^^^^^^^^^^
AttributeError: 'str' object has no attribute 'tzinfo'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 471, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 749, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 850, in add_to_platform_finish
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 590, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 654, in _async_write_ha_state
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 596, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 532, in state
raise ValueError(
ValueError: Invalid datetime: sensor.bike_last_warning has timestamp device class but provides state unknown:<class 'str'> resulting in ''str' object has no attribute 'tzinfo''
Hi, Andy! Thanks for reporting these errors. I'm indeed getting the 1st one too. I'll take a look at both of them when I have some spare time.
As you mention this is a problem with the API server (on their end). It even crashes when you try to fetch the warning messages in the official app v1.0.7 (going to menu > Message > Alarm Message), which is the latest version afaik.
When intercepting traffic from the app you can see that it simply returns this response with no further details:
{
"success": false,
"status": 999,
"message": "System Error",
"data": null
}
I'm afraid that we'll have to wait for an API fix from Vmoto Soco.
It's interesting seeing that they stay true to form with their error codes. Unpleasant catastrophic failure is 999 on the API, and likewise when the ECU needs replacing on their bikes it's error 99 that flashes on the display.
Nice easter egg indeed (if that's in fact an intended thing), but to be honest their lack of respect for any HTTP and REST standards makes me wanna cry inside.
I forgot to mention: that response (and every other response for that matter) actually comes as 200 OK. And many other things I've seen. 🤷
It looks like the warnings endpoint started working again today, but I'm unable to reconnect the HA integration and check because it's not sending the SMS code. Can someone please confirm?
I can confirm that the last warning entity is available again.
My last warning entity has become unavailable and I'm seeing regularly errors in my log because of it.
Here's the latest one for when the integration appears to be attempting to get the information it's asking for:
Everything else appears to be working okay, I'm getting live data for battery, location, etc just as usual. I assume vmoto must have changed something somewhere. Let me know if there's anything I can provide :)