-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IOError: Received 63 bytes instead of 65 #5
Comments
This is the header received by device.get_header():
0f a8 c7 04 00 5a 00 00 00 00 0a 00 e6
{ get_current_data() expects 57 byty but receives only 55 This is the raw-data returned for the queries: - hopefully someone can read that and recognize, what 2 bytes are missing? #fetch-current-data |
Hi, Unfortunately the UVR63-1 is not supported yet by this driver, see #2 (comment). Would you be interested in adding support for UVR63-1? Maybe I could give you some hints how the data format differs from UVR1611. |
Hi. Thanks for the quick reply. I was already able to debug a bit and to get some things working by changing the expected tx_data length. Yes, please support me by interpreting the data received. According the figures shown in Winsol, the device UVR61-3 has 6 temp. sensors, 9 external DL devices, 1 volume controller, 2 analog outputs, 3 pairs of power and energy counters and 3 digital outputs. I saw that byte 1 of fetch_data_range is a counter that increases by 30 each line. Further: the date and/or timestamp seem to be encoded differently. From what I analyzed your code, it's almost not possible to reverse-engineer the sensor-data decoding without any insider knowledge. So would be great if you can support me on this topic, especially regarding the digital outputs, the volume controller and (if possible) the values from the DL-sensors (what are not shown from winsol btw). |
The exact order and sizes are:
Total: 53 Bytes (+ 6B datetime + 3B timestamp + 1B checksum = 63B total response)
Should not, but maybe I implemented it wrong (I guess I never tested it) 😉 Btw, in |
Wow, rich Info! Thx. The external DL devices (18 byte) are all 0, even though the display shows sensors 2 and 3 with realistic temperature values. Looks like DLOGG does not collect their values. |
Do you have also further I do on the header? |
I forked your repo to https://github.com/pocki80/python-dlogg-driver and put my two modified files there. They now seem to fully work with my UVR61-3:
Example of a reading:
So, to have that merged I think we should adopt the code in a way, that the device type is correctly recognized and the data-reading/decoding is done accordingly. Do you know how to recognize UVR1611 vs. UVR61-3? A byte within the header? And: will your python-dlogg-db continue to work, as the set of values changes? |
Maybe I could do that some time, but I cannot promise it.
I'm sorry but I have no idea how to connect the UVR61-3 or why the external DL devices are all 0 ;)
I guess byte 5 indicates what device is connected. Should be 0x76 for UVR1611 and 0x5A for UVR61-3. Do you receive 0x5A?
I guess it's in 10 seconds since power-on.
Nice! 👍
Yeah I would suggest to use separate objects for digital and analog outputs, that's more explicit and easier to handle.
Fetching data should be easy as the byte 5 of the header indicates what device is connected. Reading current data is a bit cumbersome because the response length depends on the connected device, so we cannot know the "rx_len". But we could first receive only one byte to see what device is connected, and then receive the rest of the response.
Probably not ;) |
Hi - well done! Anyway, I was not yet sucessfull on retreiving data from my D-LOGG device using my Raspberry Pi 3 (Stretch).
Any Idea what could fix this?
This is the output when running in python interactively:
Besides: I am wondering, why the device keeps telling "21" samples available all morning (last few hours). I installed the D-LOGG device on my UVR63-1 yesterday evening and it started with 1 sample, increasing all few minutes.
The text was updated successfully, but these errors were encountered: