Feature request: sniffer example
s0170071 opened this issue · 7 comments
as the information on the available data points is ... hm heterogeneous to say at least, how about a scanner ?
An example file to probe all data points from 0x0000 to 0xffff and return the number of payload bytes and possible interpretations as table. Skip nack errors E.g
Address bytes uint int double
0x1000 4 13 13 1.234
The size of uint and int numbers can be taken from the size of the payload.
Besides, it would probably reveal all uncertainties in error handling :-)
it would indeed be a good stress test...
Anyway, you actually van request any number of bytes and split the data into useful pieces yourself. That's how Vitosoft does it. (Viessmann's own diagnostic tool) So a sniffer would make several requests with different lengths on each address and make several transformations on each received payload.
Doable but not on my priority list
FYI, it took my useful datapoints from Vitosoft's XML files. (which you can extract without installing) And if I'm not mistaken, you won't even violate copyright because of reverse engineering is allowed for interoperabilty reasons.
I looked at those files but could not find anything useful. And there is a 180 MB XML file thats particularily difficult to inspect in a text editor :-O
Do you know what happens if I read a wrong number of bytes from a location ?
I am still looking for that weekly energy statistics and suspect that its behind one of the addresses that return an error- just because I ask for the wrong number of bytes.
Wrong button... I was under the impression the file was only 1-2MB. I searched for my heater's identification code and linked with datapoint types from another xml-file.
I'm short on time and write a guide later this week.
Just an idea, if I understand the basis of this feature request.
Not to retrieve all data but to have an DPRawXX option, where I can set number of XX Bytes and get them in an MQTT Message as a HEX string.
Test e.g. the System time with 8 Bytes at 0x088E. Read and Write 8 Bytes. Decoding and Encoding can be made on the MQTT receiver side e.g. in NodeRed. This would allow new data/address usage without big VITOWiFi extensions.
That's indeed the gist. The raw optolink just transmits bytes back and forth. Decoding them has to be done somewhere but not necessarily on the ESP.