Closed klemens-st closed 2 months ago
Hi, I'm quite sure this is not a valid frame, because the length field in the frame doesn't match the actual length. How do you receive the CAN messages?
How do you receive the CAN messages?
Let me give you the full context.
I am using a NodeMCU devkit V3 with ESP8266 connected to an MCP2515 breakout board like this one. Proper CAN termination at both ends. ESP8266 is running your heat_can firmware.
Broker is Mosquitto on Ubuntu Server 20.04, your logamatic app is intended to run on this server as well but for now I am testing it on my local PC.
The thing is: everything seems to work, I am getting monitoring data, this the the values dump:
mon/Heizkreis 1/Status1 =AUT
mon/Heizkreis 1/Status2 =Nacht
mon/Heizkreis 1/T_Rs =12.0
mon/Heizkreis 1/T_Vm =31
mon/Heizkreis 1/T_Vs =17
mon/Heizkreis 2/Status1 =AUT
mon/Heizkreis 2/Status2 =Tag
mon/Heizkreis 2/T_Rs =21.0
mon/Heizkreis 2/T_Vm =41
mon/Heizkreis 2/T_Vs =41
mon/Warmwasser/Status 1 =AUT 0x01
mon/Warmwasser/Status 2 =TAG|WARM 0x60
mon/Warmwasser/T_m =43
mon/Warmwasser/T_s =47
mon/Kessel/Brenner_s =0
mon/Kessel/Brennerstatus =0x04
mon/Kessel/Kesselstatus =0xA0
mon/Kessel/T_m =47
mon/Kessel/T_s =52
mon/Konfiguration/T_Aus =12
mon/Heizkreis 5/Status1 =AUT
mon/Heizkreis 5/Status2 =Tag
mon/Heizkreis 5/T_Rs =22.0
mon/Heizkreis 5/T_Vm =110
mon/Heizkreis 5/T_Vs =52
but
0x89
is T_Aus
which is present in the dump so it means only some frames with this ID are invalidCAN message with len != 8
, I saw on /heizung/burner/can/raw/recv/
that some frames are larger than 8, there were also smaller frames./heizung/burner/can/error/regs
I saw a few messages reading EFLG:0 TEC:0 REC:0 ROF:3
, all other error topics were empty.Does it mean it is just a matter of intermittent problems with CAN that causes invalid frames received by ESP8266?
Ok, that looks quite good. CAN messages with len != 8 are not part of the protocol, but as far as I see, those should just be ignored.
It took me some time to remember how the protocol works, to have an answer to your initial question. Multiple monitor messages assemble a data block by writing data bytes at an offset into a byte array. At the origin of the error message, the first byte of the raw CAN message is already processed, the object id.
The first remaining byte at this point is the offset in the object's byte array, which is 24 in your case, but the object only has an array size of 24. I think the reason is, that your controller provides more data than expected. I can't tell you what the data means now, but you could just increase the block size to 30 Otherwise, besides the error message, the unknown data will just be ignored.
Hi, I finally got time to play with it a bit more, so far I am getting monitoring data as in the values dump I posted in the previous message.
The first remaining byte at this point is the offset in the object's byte array, which is 24 in your case, but the object only has an array size of 24. I think the reason is, that your controller provides more data than expected. I can't tell you what the data means now,
Could you advise how I can determine this data's meaning? In logamatic4000.py
you have multiple classes for different data types, each with a specific decode
method. Should I just employ trial and error to find the right encoding?
Hi, sorry for the delay.
There is a document from the vendor which describes the "service key protocol". It has a specification of some of the data blocks, altough the data transfer is different. If nothing is in there, guessing and trail is the only choice. Change some parameter and watch what value changes and so on. From my experience, there are not many different data formats.
Hi, thanks for sharing this project.
I am just starting out and getting a lot of these warnings:
Could you help me figure this out?