NodeRed implementation

[14yannick]

Maybe it will need a bit more exchange so I suggest to discuss it here to avoid the overflow of the homeassistant thread

[14yannick]

I missed the early step of the implementation but the blog of thomas really was a good source for understanding the exchange. Maybe the motors compare the counter with the count of message before counter 35.
did you get your settings right baudrate 57600, 8 data bits, even parity and 1 stop bit?
You have also another trace here
maybe you reply just a bit early and therefore the motor is not ready to listen.

[RobinR1]

The settings of the serial port are indeed set to 57600 8E1.

I have added some timing measurements to the Node-Red implementation, and I found out that most of the time the timings between a command coming in and the response going out of the flow, is around 7 to 9ms. However some times the timings go up to 20-something ms and it looks like whenever the timings exceed +/- 12ms, the motor repeats its last message (same counter-value). So I'm suspecting that instead of too fast, the implementation is currently too slow. And I'm not sure if I will be able to guarantee somehow that a response will always be within 12ms as the UniPi device currently running Node-Red manages also other flows, part of my home automation. And it is a full blown linux running on it, which has of-course several system processes consuming cpu time.

I'm still not sure if that really is the cause, but it seems like whenever that has happened at least 2 times the motor stops communicating about 22 messages later than the last time it repeated a command. It is still a bit of a wild guess but that is currently the only pattern I can find in the logs of the few times I tried currently. I find it weird however that it doesn't go into error, but just stops communicating. (the total number of messages does vary and is not fixed to 34 like I said in last forum post)

Also strange is that even when the motor is then power-cycled, it just sends the bus-scan command to the known slave ID, which I reply correctly to and then nothing more.. (only one time in the beginning of my tests, the motor then started communicating again for a few seconds, but currently I have not seen that happen again and it just doesn't communicate anymore after sending that initial bus-scan command during motor start-up) I have to manually perform a full bus-scan again before the motor communicates again for a few seconds.
I have also (accidentally :-)) reset the motor back to factory default, but that didn't change the observed behavior.

I'll try to test again tomorrow a number of times and save the logs to share and compare them..
I'll also try if it makes any difference in timings if I give the nodered processes a higher priority (nice level)

[RobinR1]

side note: Whenever I send invalid replies, or no replies after a successful bus-scan (shows "1" after scan), the motor does go in error and displays "04". But I have not yet seen error "07"

[RobinR1]

I'm afraid I have to give up. I tried many things but NodeJS/NodeRed on a multi-tasking OS is just not responsive enough, it seems. When prioritizing Node-Red with nice -20, and optimizing as much as I can both on OS and in the Node-Red flows.. I had it communicating for almost 10 minutes and the average response time of NodeRed was now around 4-6ms.. but still sometimes it took just a bit longer.. and once or twice it took over 12ms and a few messages back and forth later, the motor stopped communicating again..

Meanwhile there has been a major OS update of the Unipi from Debian 10 to 12 and Node-Red was also updated from v2 to v4 and according to Unipi there where RS485 performance optimizations in this release.. so I retried everything..
I had a bit better average timings, but still it just regularly takes too long to answer for the motor to stay happy.

I assume this is the reason why in the original code, there is a CPU reserved exclusively to processing the communication.

So I'm bailing out here and will soon buy or assemble a dedicated ESP board for it..

[14yannick]

sorry to here this.
you probably check it already do you have any delay here?

If you need any hardware you can DM me in here

[RobinR1]

I did not use the modbus-client node since it did not support the FC23 request, at least not back then and on the NodeRed version I was using (v2.x). So I had to use the default serial-in and serial-out nodes, and manually parse and assemble the modbus messages including the CRC calculations.
I see now that the modbus-client node has seen new development as of the beginning of 2024 and should now support custom FC definitions. And as UniPi is now able to run nodeRed v4, I could retry using this modbus-client node...
But as in all my tests, I saw the shorter the response time of the Node-Red flow was, the longer the communication with the motor lasted, so I'm fairly certain my communication protocol was correct, so I fear retrying it with the modbus-client node will not change much..