svalouch
commented
3 years ago Thanks for testing these! Some OIDs carry sets of information, such as battery.cells[x] which seems to carry 3 values for each of the 24 cells in an RCT battery module (Device > Measured values > Battery, then the last entry that starts with Battery sn: and then select the first battery module for battery.cells[0]). I'm actually trying to reverse-engineer how this one works for some time now.
Anyway, these were all in the original code and marked as "string" there, and there are some more that depending on the device's state may return things that can't be converted to strings, i.e. the value may be convertible by accident. I haven't wrote them down when I encountered them, unfortunately, but looking through the app I see additional candidates: logger.buffer and the annoying net.package (the device proactively sends these to any connecting client every few frames if it's in master mode) and some other network-related OIDs.
I don't have a good idea what to do about them, though the error "message" should be improved, that's for sure. I don't want to block these from being queried, but I don't have a good idea how to return a value for them either. I've been thinking about returning a hexadecimal representation of the bytes, question is how. Catching the exception doesn't work reliably, and that would make scripts that use this unreliable. However, as their structure is unknown anyway, declaring them as returning "unknown" data rather than "strings" might do the trick. Anyone using the project as a library (which is the original intention) can do the decoding themselves if they know how to (and hopefully contribute back), so it won't impact those users.
Today I created a little script to read all the OIDs referenced in the documentation. With at least three OIDs I have issues. For the following three:
Cathegory OID Name bat_mng_struct 0x9DC927AA bat_mng_struct.profile_load battery 0xF8C0D255 battery.cells[0] net 0xC0A7074F net.slave_data
I'm getting the following output:
pi@vm-pi:~ $ rctclient read-value --verbose --host 192.168.0.1 --name net.slave_data Traceback (most recent call last): File "/home/pi/.local/bin/rctclient", line 10, in <module> sys.exit(cli()) File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__ return self.main(*args, **kwargs) File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main rv = self.invoke(ctx) File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke return ctx.invoke(self.callback, **ctx.params) File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke return callback(*args, **kwargs) File "/usr/lib/python3/dist-packages/click/decorators.py", line 17, in new_func return f(get_current_context(), *args, **kwargs) File "/home/pi/.local/lib/python3.7/site-packages/rctclient/cli.py", line 197, in read_value value = decode_value(oinfo.response_data_type, rframe.data) File "/home/pi/.local/lib/python3.7/site-packages/rctclient/utils.py", line 121, in decode_value return data[0:pos].decode('ascii') UnicodeDecodeError: 'ascii' codec can't decode byte 0xfb in position 3: ordinal not in range(128) pi@vm-pi:~ $the three values as such might be not important but ... you might want that rctclient will work with any OID. Hop that this is not only a local problem. I have retried the three OIDs several times with same result.