Do not error out on malformed JSON #7
Conversation
Once our RFC 3 (FW version B3.5.50) gets connected to the network, its `net_status` JSON data include the `ip` and `mac` fields whose values are binary strings, and that results in a Python-level exception: UnicodeDecodeError: 'utf-8' codec can't decode byte 0x9e in position 713: invalid start byte The `mac` is a 12-byte string for me (unless all the escape sequences failed me, it's really late). I have no idea what that is, whether it's something related to BLE MACs (two addresses in a row?), or something to do with cryptography. The `ip` is a four-byte string which for me is `L^\x9e\xbe`. No matter what byte order I use, it doesn't map to the IPv4 address that our home is NATed behind, or (according to whois) to any obvious cloud provider. Another mysterious field. No matter what these fields are, let's not break JSON parsing, and let's keep as much info as possible (which is why I picked that particular error handler as per PEP 383).
|
It's probably encrypted, did you try use method decrypt from utils.py? |
No joy there, it's not a base64 string. And when I base64-encode it first and then feed that stuff to Anyway, I'm behind a carrier-grade NAT, and I'm getting I reconfigured my router so that it assigns a different address, |
Once our RFC 3 (FW version B3.5.50) gets connected to the network, its
net_statusJSON data include theipandmacfields whose values are binary strings, and that results in a Python-level exception:The
macis a 12-byte string for me (unless all the escape sequences failed me, it's really late). I have no idea what that is, whether it's something related to BLE MACs (two addresses in a row?), or something to do with cryptography.The
ipis a four-byte string which for me isL^\x9e\xbe. No matter what byte order I use, it doesn't map to the IPv4 address that our home is NATed behind, or (according to whois) to any obvious cloud provider. Another mysterious field.No matter what these fields are, let's not break JSON parsing, and let's keep as much info as possible (which is why I picked that particular error handler as per PEP 383).