DIYEFI.org Forum

malcom2073 wrote:As per a document I'm assuming Fred already sent you (If he did not, ask and I'll see if I can find it again)

Yes, this is the first thing I did, and asked him not to share on the forum as they're out of date and should not become a defacto standard. This is one of the things he meant by secrecy above.

Now that you have the packet read, you should de-escape the bytes. Once again that is documented in the protocol document which bytes mean what. Once all that wonderful magic is finished, you now have a complete datalog packet.

I sincerely hope that you do NOT do it like this!!!! Reading guts out of the packet before deescaping and checksumming is completely flawed! The packet must be received, deescaped, and checksummed IN THAT ORDER. ONLY then can the header be read and the contents interpreted appropriately.

The datalog packet format <SNIP> but be advised, this is subject to change as the datalog format will in the future be configurable.

The datalog packet format <SNIP> but be advised, this is subject to change as the datalog format has been configurable for more than two years.

Fixed! I've used it several times over that period when I've needed specific data at a higher frequency. You just have to change your external tooling to suit. Laborious, but only a little.

Fred wrote:I sincerely hope that you do NOT do it like this!!!! Reading guts out of the packet before deescaping and checksumming is completely flawed! The packet must be received, deescaped, and checksummed IN THAT ORDER. ONLY then can the header be read and the contents interpreted appropriately.

Of course, I misspoke. You don't touch the header bytes until after you escape the whole thing and verify the checksum.

Thank you so much malcom2073.

Wilbert

Fred wrote:

malcom2073 wrote:As per a document I'm assuming Fred already sent you (If he did not, ask and I'll see if I can find it again)

Yes, this is the first thing I did, and asked him not to share on the forum as they're out of date and should not become a defacto standard. This is one of the things he meant by secrecy above.

I know it has been a while, I wonder if a more current version of protocol documentation is available anywhere? I would assume even an outdated document would be much better than nothing?

Poor assumption.

Fred wrote:Poor assumption.

No worries, I can always take the longer route. Thank you for help!

You're welcome. You need all the help you can get. :-)