Car integration
-
toggledbitsreplied to rafale77 on Mar 9, 2021, 6:01 PM last edited by toggledbits Mar 9, 2021, 1:15 PM
@rafale77 said in Car integration:
Note: After updating to 21067, I am getting new errors on both the hass websocket connection and the openLuup connection as shown below:
Cover/position messages are just my midwork at getting the cover domain working on Hass when I don't own any cover devices myself. File attached should quiet those messages.
The message on the openLuup side is pretty dire. It suggests that either the user_data or status response
devices
astates
subkey is not an array, and that is unexpected. What version of openLuup are you on? -
I am running 21.03.04. I will update when I get a break from work.
-
No need, I think I know what it is. Since openLuup is implemented in Lua, unless you take special action, the JSON library doesn't know whether to convert an empty table to array form
[]
or dictionary form{}
, so it defaults to the latter. So I suspect there is some device of yours that has no states, so thestates
array is empty, and openLuup's JSON library is emitting{}
for it instead of[]
, and the more literal parser in node/JS, which of course does distinguish between empty array and empty dictionary, is seeing an unexpected data type and therefore doesn't have a member method it wants.I can code around it, but I think @akbooer should also guard for empty tables in his code so that the response format stays consistent (with both itself and Vera Luup). I had to do a bunch of this my Lua plugins that use JSON, too.
-
@toggledbits said in Car integration:
I think @akbooer should also guard for empty tables in his code
Happy to help. You’re suggesting that any empty table should be reported as an empty array?
-
@akbooer said in Car integration:
You’re suggesting that any empty table should be reported as an empty array?
Not exactly. I'm saying it should be emitted consistent with its usage. In this case, the
states
key should always be an array. So it should be an array whether it is empty or not. In another place (no example comes to mind) where the expected data type would be an object, then it should be an object whether it contains keys or not. -
Not so easy, then. To me, this is not a very clever use of JSON, ascribing meaning when there is none, really.
-
Actually, it's Lua's fault, because it doesn't give JSON any hint to know if any empty table is actually an empty array or an empty object. But it has significant meaning to clients using your JSON output. If
states
is meant to be an array, then it should always be an array and formatted as one in the JSON output. That's the definition of data returned by Luup. If the data types are not stable in an API, that makes it pretty hard to make sure code that uses the API can handle the responses, as in this case. -
Was playing with the notification service to send messages to the car from openLuup. Not very useful on my car since it shows up in the mail box and not on the dashboard forcing me to navigate to go look at the message... oh well. It's there now if I ever want to do something with it. I will make do with honking for now.
-
Subaru owners with an active StarLink subscription may wish to explore https://pypi.org/project/subarulink/
18/19