Debug not working? Strange Modbus behaviour when using 2 EVSE's

[niekvanprooijen]

I have v1.5.2 running on a SmartEVSE3. I set DBG to 1, recompiled and flashed. Telnet is available when connecting and the welcome screen is displayed. But no debug messages are displayed. Is it broken or do I miss something?

[dingo35]

How about when you choose debug level v = verbose ?

Enter key after v ....

[niekvanprooijen]

Nope, nothing.

[dingo35]

You are probably in Normal mode; in that case the only thing to display is modbus traffic; you probably have no modbus devices attached?

If you change to Smart, Solar or Off mode you will see the normal State line ....

I know this seems odd behaviour, but guess what, it has always been this way? I'm going to rethink the place where the State line report is placed ......

[niekvanprooijen]

I have 2 EVSE's connected. Both are in Smart mode. 1 is load balancing master and 1 is Node1. Mainsmeter is set to API and receives data from HASS (which works) The one I'm trying to debug is Node1 as it is giving a ERROR NO SERIAL COM CHECK WIRING message. There is also a Eastron kWh meter connected but this one is configured in the master. As I look at it now this communication is not working anymore as I see NO communication symbol on the Eastron.

[dingo35]

Ok I have only 1 EVSE so I cannot test this myself.

On the Master EVSE you should see modbus messages on the debugger, at least to the Eastron, and hopefully also to Node1. Could you post those messages?

Also: is this your first serkri flash, or did you have earlier serkri versions that worked?

[niekvanprooijen]

This is what I see on the master.

Also: Yes this is my first Serkri version. Haven't tried another one yet. I have no sensorbox as I want to communicate with HASS anyway to enable/disable charging when the price is low.

[dingo35]

I would expect modbus request 7 to be sent to Node 1.

I have never heard of problems with multiple EVSE's with the serkri distribution, but on the other hand, not many people have more than one.... so you might be the first user to encounter this problem.

I think the easiest way to locate the problem is to first try serkri release 1.0.0, if that works, try 1.3.0, if that doesnt work go down a couple of versions, if it does work, go up a couple of versions. If you can pinpoint me to the release where it stops working, I´d be happy to try and pinpoint the exact commit that introduced the problem, and then fix it ....

[niekvanprooijen]

So I did some testing and found the following behaviour: V3.0.1 works properly. Modbus communication with node AND EASTRON WORKS. Continu to work after power cycle. V1.5.1 works properly after update. First firmware.bin then spiffs.bin. Mainsmeter API works. After reboot from website NO communication with EASTRON and Node1 gives error ERROR NO SERIAL COM CHECK WIRING. No change when re-uploading firmware.bin or spiffs.bin After uploading v3.0.1 to only Master communication with EASTRON is up again. After uploading v3.0.1 to Node1 communication no more errors in display. after uploading v1.5.1 to master communication with Eastron is still alive. No errors on Node1. change mainsmeter to api --> works. After rebooting devices (power cycle) NO communication with Eastron AND communication error on Node1. After uploading v1.5.1 to Node1 NO change. Still error on Node1 and NO communication with Eastron. After uploading v3.0.1 to both everything is fine again. Even after reboot (power cycle) After uploading v1.3.8 to both devices (firmware and spiffs) all works. also after reboot. Change mainsmeter to api on master. works. After powercycle NO communication with Eastron. Change mainsmeter to sensorbox on master. Error on master NO COMM etc. After reboot communication with eastron works again, no errors in display After uploading v1.5.2 to both devices (firmware and spifss) all works. also after reboot. change mainsmeter on master to api --> works After powercycle no communication with Eastron and no communication error on node 1.

Edit: additional tests and it seems like to problem is located: after changing the mainsensor on the master to API it initially works, but after rebooting the devices (powercycle) all modbus communication seems lost. This sounds like a startup problem where the modbus is not initialized when mainsmeter is set to API or something else then sensorbox. Does this help?

Edit 2: Maybe this at line 2558 in evse.cpp: void ConfigureModbusMode(uint8_t newmode) {

if(MainsMeter == EM_API) return;

I guess this means when set to API the modbus is not initialised properly.

[dingo35]

Hi Niek, this looks promising, it sure helps! Unfortunately I'm currently traveling so I can't look at the code, please keep up the good work, in a few days I'll be back online!

[niekvanprooijen]

Commenting out the mentioned line fixed my problem. Looking at the code I do not see the reason the line is there anyway. ModBus now works on both devices as well as Telnet debugging.

[dingo35]

At first glance I think you are right, but that part of the code is new to me, and I am not near my SmartEVSE so I cannot test on the real device ...

@k-janssens : this line was introduced in commit f84ecae3 where you introduced the EM_API, do you see any harm in removing this line?

[k-janssens]

I added that line to avoid the system trying to get data from the sensorbox, maybe it isn't necessary but it could be a problem if you have a SB connected and also send power data through the api giving conflicting results

[dingo35]

@niekvanprooijen This makes perfect sense; I want to sleep over this. I suggest you keep your private version running and we keep this issue open so we don't forget until definitely solved. Big thanks for all the work you did!

[altrnate32]

I added that line to avoid the system trying to get data from the sensorbox, maybe it isn't necessary but it could be a problem if you have a SB connected and also send power data through the api giving conflicting results

I think you tackle that already in line 2581

[dingo35]

@altrnate32 , I think you are right when running on a node , but when you are running on a master or loadbalance is disabled (if (LoadBl < 2 ) ) that doesn't fly....

[niekvanprooijen]

I will keep my current custom version for now. Thanks for looking at this issue!

[djoenez]

I seem to be having the same issue, EVSE1 (which is master) is receiving data via API (from hass). I cannot connect to Node1 or kWh meter (also tried only node1, only kwh meter, switching cables, removing ground, swapping master and node1).

I do not know how to compile, Niek, could i use your version to check if this fixes the problem in my situation too?

[dingo35]

UNTESTED-master-20230221+nodes-fix.zip @niekvanprooijen @djoenez: I attached a debug-compiled version of the current master branch that has a possible fix attached.

Since I'm not at my SmartEVSE location, I cannot test this fix myself, so I would like to ask you to test it for me.

In the fix the offending line is removed (thanks niek!), also it is now possible to configure MainsMeter to Disabled (please test if this works ok in the glcd menu!). If Mainsmeter is disabled, only Normal mode should be possible. And of course, your main problem, communication between multiple EVSE's should work again.

Have fun!

[djoenez]

Thanks alot, I will test it tonight and report back :).

[niekvanprooijen]

Great! Modbus works. Left (249) is master. Set to off because no EV connected. Right (250) is slave. Charging a vehicle. Current(s) from EV meter are received. Only EV power remains 0.

[djoenez]

Works like a charm! Just had one blank screen on the EVSE1, don't know what happened there. no problem after reboot.

[dingo35]

Ok thanks for testing! Im aiming to merge this into master after some testing of my own...

[evanes68]

Works for me too. I use the combination with API for mains meter and Modbus for EV meter.

[bartv]

Works for me as well. Is the source available of this fix? I would like to try out some things but for that I need a working EV Meter.

[dingo35]

Next week Im able to push this into the main branch...

[dingo35]

Merged into release 1.5.4