Crash on dimmer

[cyclops1982]

...WSConn::send: {"domain":"light","id":42,"service":"toggle","target":{"entity_id":"light.tv_room_dimmer"},"type":"call_service"}
* WS-ENC: sending [TEXT payload=0/113]
* WS-ENC: buffered [TEXT payload=113/113]
* WS: flushed 119 bytes
* WS-DEC: decoded [TEXT payload=0/333]
* WS-DEC: passing [TEXT payload=333/333]
Event type received that we didn't expect: "call_service"
* WS-DEC: decoded [TEXT payload=0/1216]
* WS-DEC: passing [TEXT payload=1216/1216]
No colormode...
UPDATED STATE FOR TV room dimmer:{
  "attributes": {
    "brightness": null,
    "color_mode": null,
    "friendly_name": "TV room dimmer",
    "supported_color_modes": [
      "brightness"
    ],
    "supported_features": 32
  },
  "context": {
    "id": "01J6XTHJP5S9TF7K9BZGBD1JBN",
    "parent_id": null,
    "user_id": "237eddb8413b45868a4c2c4817a27e27"
  },
  "entity_id": "light.tv_room_dimmer",
  "last_changed": "2024-09-04T06:11:27.084713+00:00",
  "last_reported": "2024-09-04T06:11:27.084713+00:00",
  "last_updated": "2024-09-04T06:11:27.084713+00:00",
  "state": "on"
}
terminate called after throwing an instance of 'nlohmann::json_abi_v3_11_2::detail::type_error'
  what():  [json.exception.type_error.302] type must be number, but is null
Aborted

Just logging so i don't loose the logs

[Habbie]

@cyclops1982 also points out that "we did not understand this update" should not crash the entire process :)

[cyclops1982]

This was on #108

[Habbie]

@cyclops1982 also points out that "we did not understand this update" should not crash the entire process :)

#113 makes exceptions during after-startup update processing not crash the process. This leaves the update() call in places like the UIRGBLight constructor, which requires a bit more thinking.

[cyclops1982]

* WS-DEC: passing [TEXT payload=1206/1206] 
...* WS-DEC: decoded [TEXT payload=0/1140]
* WS-DEC: passing [TEXT payload=1140/1140]
......* WS-DEC: decoded [TEXT payload=0/1079]
* WS-DEC: passing [TEXT payload=1079/1079]
* WS-DEC: decoded [TEXT payload=0/1071]   
* WS-DEC: passing [TEXT payload=1071/1071]
* WS-DEC: decoded [TEXT payload=0/1205]   
* WS-DEC: passing [TEXT payload=1205/1205]
..* WS-DEC: decoded [TEXT payload=0/1172] 
* WS-DEC: passing [TEXT payload=1172/1172]    
* WS-DEC: decoded [TEXT payload=0/1184]   
* WS-DEC: passing [TEXT payload=1184/1184] 
..* WS-DEC: decoded [TEXT payload=0/1618] 
* WS-DEC: passing [TEXT payload=1618/1618]
* WS-DEC: decoded [TEXT payload=0/1117]   
* WS-DEC: passing [TEXT payload=1117/1117]
.* WS-DEC: decoded [TEXT payload=0/1470]  
* WS-DEC: passing [TEXT payload=1470/1470]
* WS-DEC: decoded [TEXT payload=0/1430]   
* WS-DEC: passing [TEXT payload=1430/1430]
..* WS-DEC: decoded [TEXT payload=0/1169] 
* WS-DEC: passing [TEXT payload=1169/1169]
* WS-DEC: decoded [TEXT payload=0/1197]   
* WS-DEC: passing [TEXT payload=1197/1197]  
.* WS-DEC: decoded [TEXT payload=0/1079]  
* WS-DEC: passing [TEXT payload=1079/1079] 
* WS-DEC: decoded [TEXT payload=0/1071]   
* WS-DEC: passing [TEXT payload=1071/1071]
* WS-DEC: decoded [TEXT payload=0/1204]   
* WS-DEC: passing [TEXT payload=1204/1204]   
..* WS-DEC: decoded [CLOSE payload=0/2]   
* WS-DEC: passing [CLOSE payload=2/2]   
terminate called after throwing an instance of 'nlohmann::json_abi_v3_11_2::detail::parse_error'         
  what():  [json.exception.parse_error.101] parse error at line 1, column 1: syntax error while parsing value - invalid literal; last read: '<U+0003>'                                                             
Aborted                                

I think this is a different crash. We miss some debug info to understand what the string was we received.

[Habbie]

definitely different, the first post was "we asked something of the json object that it only had in another type" and this one is "whatever we got from HA was not JSON".

debug logging will increase until morale is improved!

[Habbie]

..* WS-DEC: decoded [CLOSE payload=0/2]

oh, it's a CLOSE!

[Habbie]

From https://en.wikipedia.org/wiki/WebSocket

The payload is optional, but if present, it must start with a two-byte big-endian unsigned integer reason code,

These status codes are in the 1000-1015 range, or hex 3e8-3f7, which explains the <U+0003> I have also experienced before.

[Habbie]

#114 slightly improves the WS_CLOSE situation (and gives us a spot to work when we want to do better)