Reliability of BM2 as standalone option

[joelucid]

Hey there,

I'm having the hardest time sending data to my ZWR 18-5 via a BM2. If I connect the outside temp sensor to A/F I get error CC during startup. If I hook up the BM 2/2 code resistor it starts up and sends CAN messages which I can receive. But after some time I then get A8.

Send levels look ok. The ZWR does acknowledge the packets I send. But it seems to discard them.

Maybe the BM2 has trouble working without a BM1 in a cascaded unit?

I should say that I used a esp32 with a SN65HVD230 module. I had to reduce clock frequency to 26 MHz to be able to run the internal CAN support at 10 kbit/s - which meant commenting out anything wifi related since that would hang at lower CPU speeds.

Anyway I read in the mikrocontroller thread that you'd had issues sending data as well - so wanted to see if you could summarize your latest findings. I know you've been skeptical rg the SN65HVD230 - but it works fine for rx at least.

[Neuroquila-n8fall]

Hello,
I'll summarize this issue as short as possible by saying:
Avoid the SN65HVD230 and use MCP2515 instead. I had no luck running this thing below 100kbit/s. The clock of the ESP32s CAN controller simply isn't designed to run a bus that slow.

Other than that you should be perfectly able to communicate with the BM2 module but be aware that in some cases the heating will ignore settings and this may be due a faulty mainboard. Many of the errors related to values not being sent or received properly or the heating itself is steering the temperatures completely wrong are related to failures of the mainboard. Keep that in mind when testing ;)

[joelucid]

Is there a command I could post which would immediately result in feedback so I could probe addresses? Btw do you know if A8 goes away if correct data is received? Or do you have to restart the ZWR? I do get the error code via can bus - if it does go away I could probe until its gone.

[Neuroquila-n8fall]

0xF9 with no payload will trigger a data send event on the main boiler controller. That messages also actively prevents any A8 error.
If that isn't happening I have to admit right now I'm really not confident enough to say something is off with your setup or it's a completely different thing when using cascaded devices.

So, to clear things up I recommend hooking up the original TAxxx controller and have the ESP32 just listen for messages. In the most recent version you will find that can-analyzer part which outputs all the messages found on the bus, excluding the known addresses. Use that to pick out the messages which are unknown. With that dataset we can look into what may or may not be the BM2 ID. Please take also note of the values of the boiler so we have something to look for. You will also see if data changed, take special note of those:

I think we need to send something special on the bus on cascaded layouts so it won't turn into an A8.

[joelucid]

My problem is I have the TA 211 E - so not can bus based. With the BM02 in place instead I see the same can bus messages regularly sent as you have above but starting from 0x230. They do have the right content too - like I can see the error code A8 at the right offset. The BM02 sends these packets even without being triggered with 0xf9.

My hypothesis is that each of the cascaded devices sends status packets at a unique range of addresses and is controlled by a unique range of addresses. To check if that's correct I want to send the minimal commands necessary to reverse the A8 error code (if that's possible without restarting the boiler). If you can tell me which commands would do (like in the microcontroller thread someone said just sending a valid command without argument would prevent A8 - but would it also reverse it?) I can just have the esp probe all possible addresses until A8 disappears.

If that won't work I guess I'll have to buy a BM1 after all. Or use 1-2-4. Would very much prefer can bus though to have the live state available for control purposes.

[joelucid]

Just getting a can bus based TA xxx controller has a high risk of not working since device number 1 in the cascade would then be missing.

[joelucid]

BTW - it's possible that the controller will send a keep-alive even to a cascade instance 2 even if the instance 1 is missing. If you have a BM2 (I think you have the version which acts as BM1 with outside thermometer attached) you could replace the AF with the coding resistor for instance 2 and we might at least have the keep-alive address.