Support the complete ebus arbitration protocol #40
Conversation
guido4096
commented
Apr 13, 2023
guido4096
commented
- Only allowed to participate when the bus is in state "Received First Syn"
- Participate in second arbitration round when priority class matches
1) Only allowed to participate when the bus is in state "First Syn" 2) Participate in second arbitration round when priority class matches
|
P.S. the code became quite a bit more complex. I didn't find a reasonable way to do it easier. The ebus protocol is interesting for arbitration, you really need to monitor the bus continuously to assess the state and to find out who won. Without these changes , you run the risk of disturbing the good working of the ebus:
|
|
Thank you for this. I |
|
of course; I'm still testing here and keep debugging |
|
@brozikcz maybe you want to test this one? |
|
After lots of testing, I added an additional change that improved the interaction with ebusd significantly. as much as I can tell, ebusd expects to receive the starting SYN symbol when starting the arbitration. |
|
I’m still having unpredictable behavior. There is at least one bug present with the priority class. Better to wait until i finished all testing. |
Add DEBUG_LOG statements Make sure no WIFI communication during arbitration Avoid lockup during arbitration loop Handle unexpected state during arbitration
|
Had a rough day yesterday evening, ebusd was just not interacting well with the adapter at all. This morning, same code, all works more or less flawless. Either related to my devices on the ebus, or to the wifi. Anyways, this state is at this moment working well for me. Also added DEBUG_LOG statements that are removed using a #define |
|
Below is a nice example of the arbitration working.
CMD_START 0xf3 |
Minor updates to make the code more readable Add all states when to abort to switch statement
|
By now I observe only the following problems:
The third item is the most difficult one to resolve. I think with the Arduino framework it is not possible:
I believe this problem can only be solved when handling the arbitration in an interrupt, which is not supported by the Arduino framework - to my knowledge. Fortunately it doesn't happen too often. Note: all these problems are gracefully handled, ebusd reports on them and retries as needed. Typically the command will pass. Most of the time the command passes without any hiccups at all, you have to do stress tests to see the issues. But of course, the system should behave well in stress tests.... Example of problem 1CMD_START 0xf3 Example of problem 2bCMD_START 0xf3 Example of problem 3CMD_START 0xf3 Example of problem 4CMD_START 0xf3 Example of lost arbitration and retryCMD_START 0xf3 corresponding ebusd messages |
|
Hi guido4096 |
|
@PiotrHab, Thanks for suggestion. I expect that would cause more occurrences of item 1. To fix the remaining issues, I still think there are two things needed:
|
|
@guido4096 , could something like SoftwareSerial help with 1.? For 2. I was long asking for this but without any reply: |
I don't see how SoftwareSerial can help. What is happening:
The ESP needs to receive the character from ebusd and put it on the bus within about 45 ms. If not done in time, the AUTOSYN will detect that the bus is idle for 45 ms and will send a SYN. |
|
Sorry, I meant it as solution for this one:
|
ebusd looks like it has grown over time and It now has many different responsibilities mixed in one code base that is difficult to understand and to maintain in a predictable way.
Maybe better to just create something new, without all the overhead of ebusd. Something that is only able to understand the lowest layer of the protocol and leaves all the interpretation to somebody else. The lowest layer should be implemented completely on the ESP. It should forward what it reads - like it already does - and support a full message protocol for writing and including sending the reply of the message to the requester. So something like what you described here: john30/ebusd#124 |
I don't know enough how SoftwareSerial works. Does it allow bit precise interaction with the signal? If you get signaled per bit, at least you know better the exact timing. But still if you don't have interrupts you cannot guarantee that you can reply in the right time. |
|
P.S. with the changes on this branch, I think you are close to what ebusd-esp is doing. I think ebusd-esp will have the same problems with wifi as the code on this branch. Of course if they connect to a dedicated raspberry pi, the problem should not occur as latency is more predictable. But that is just not a right solution, it spreads a single responsibility over two different devices. I think the only good solution is what you already requested here john30/ebusd#124. Still then, to get everything in shape, the arbitration protocol itself needs to be closer to the hardware than it is now, ... my opinion based on all the testing and timing problems I observed. |
not clear why.
|
@danielkucera I believe the current code is good for esp32, using SoftwareSerial and ASYNC mode. There is maybe a slightly more tweaking possible on timing delays with arbitration, there is a fudge factor of 700 micros in the code, which I derived by testing ... a lot. The current code uses SoftwareSerial to get the exact flange of the start of the startbit. It requires a specially adapted version of that software though. The included statistics, available using the status webservice, should give feedback how things work for other users. The code builds for esp8266, using SoftwareSerial and SYNCHRONOUS mode. This setup also works on esp32 and testing it gives quite ok results, although ASYNCHRONOUS works better for the esp32. Code is documented on the non-obvious parts, quite a number of them available dealing with SoftwareSerial and vTaskDelay. Maybe there is still some cleanup possible with the debug messages, might still do that. I would be really interested in experiences from other users... |
|
Hi @guido4096 , was your order number 2748? |
|
Yep |
|
Hi @danielkucera , I received two modules, thanks! I just finished testing the esp8266 - version v4. With the original code I had quite some errors icw ebusd, the new code behaves much better, at least for me, icw SoftwareSerial and plain synchronous mode. The three main high-level improvements in the code are:
I think the item 3) helps to keep the wifi connection more responsive. Note that the esp8266 has less memory than esp32 and SoftwareSerial uses more memory because it needs to store the timestamp. To avoid heap exhaustion, I needed to reduce the receive buffer size to 512. This is more than 2 seconds, so this should be more than enough. I think even 256 should be enough. |
| @@ -48,6 +49,9 @@ platform = espressif32 | |||
| board = esp32-c3-devkitm-1 | |||
| build_flags = | |||
| -DRESET_PIN=20 | |||
| lib_deps = | |||
| https://github.com/tzapu/WiFiManager | |||
| https://github.com/guido4096/espsoftwareserial.git#add-startbit-timestamp | |||
There was a problem hiding this comment.
@guido4096 , did you consider creating pull request to the original library?
|
I did ask: plerup/espsoftwareserial#287 P.S. still testing. The ebus of my heating system crashed a few time with the esp8266, now testing with the original firmware. |
|
Hi @guido4096 , can we merge this? Is it running fine? |
|
Hi @guido4096 , do you have any update? |
|
Hi Daniel, sorry for the late reply. The code itself is running fine, however i see with the esp8266 that my heating system goes faster into error mode. Like once every two days instead of once every 5 days. I think this means the code uses more power? This is reduced if i use hardwareserial for the rsp8266, i cant say if it is the same as with the original code. Ill upload the current code in the evening to have all settings I use depending on chip type. And then ill start another test with the esp8266 while connected with external power, so see if that indeed fixes the bus. Guid |
|
Thank you for the update. Let's merge this one with what you have and then if you wish, you can optimize for esp8266 (but you don't need to invest much time into this honestly). I am thinking about putting the bus handling into a separate task (outside of loop() ) and I don't want to refactor everything again after this is merged :) |
|
I just pushed the latest changes, they are small. Shall I return the two adapters that you gave me for testing back to you? |
|
No, you can keep them, thank you for all that work. |
