DemandShaper/OpenEVSE/ Unresponsive

Integrations OpenEVSE
1

Hi

Just had OpenEVSE installed.

All working correctly from the OpenEVSE web page and I have initiated a charge.

Set up Emoncms and mostly seems OK but I suspect I may have misunderstood the instructions. Inputs are posting and DemandShaper OpenEVSE appeared as per instruction.

However when I open DemandShaper OpenEVSE I get this

demandshapererroe
demandshapererroe1005Ă—455 12.1 KB

Searching forum I discovered that the I had the MQTT topic wrong so I changed it from openevse to emon/openevse.

Unfortunately it has not solved the problem. The odd thing is I set a manual charge and the charge current is showing in demandshaper!

In addition I have an error popping up in Inputs that I cannot get rid of. A post from @TrystanLea suggested
redis-cli flushall but that made no difference.

deviceerror

I suspect this may be caused by the initial MQTT topic error but I now have the 2 problems and I do not know what to do next. The error creating device is a real problem as it pops up so frequently I cannot make any changes in inputs.

Log attached:-

LAST ENTRIES ON THE LOG FILE
2020-09-13 09:30:39.169|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:30:42.661|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:30:48.055|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:30:56.166|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:33:51.781|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:34:00.043|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:34:02.973|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:34:07.131|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:34:11.271|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:46:51.352|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:46:53.771|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:46:58.815|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:47:04.874|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:47:06.414|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:47:09.706|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:47:14.785|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:47:17.543|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:47:28.307|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:47:31.806|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:47:57.613|ERROR|demandshaper_model.php|Saved to disk
2020-09-13 09:59:21.271|WARN|emoncms_mqtt.php|Not connected, retrying connection
2020-09-13 09:59:21.301|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0
2020-09-13 10:00:45.522|WARN|device_model.php|Device model: Requested device does not exist for id=0
2020-09-13 10:37:13.371|WARN|device_model.php|Device model: Requested device does not exist for id=0
2020-09-13 10:42:04.680|ERROR|index.php|Not Authenticated|feed/list

Open EVSE services:-

openscreen
openscreen1022Ă—707 76 KB

2

Hi,

not sure but the MQTT port looks wrong as I think it should be 1883

John

3

My MQTT server is on a different PI with custom port number. Connected and posting to Emoncms. It’s just demandshaper that’s not working properly.

4

Hello @ian

It’s probably best to start from the inputs page error and then move to the demandshaper. Strange that redis-cli flushall does not fix the issue.

Perhaps check the device list here, for an openevse entry:

http://192.168.1.22/device/view

You could try deleting it if it exists and seeing if the error goes away?

5

Deleted from /device/view

Still have error

There was an error creating device: nodeid=openevse message=Device already exists

Checked

OpenEVSE disappears from view list when you click delete. But I issue the /device/view command again and its back on the list!

indestructible…

6

Hi @TrystanLea

having resolved the device errors with your prompt assistance I am now back to trying to control OpenEVSE from demandshaper.

When I first open the OpenEVSE DS window it shows red for 30 seconds or so.

Then it shows OpenEVSE Unresponsive and remains in that state.

However the temperature appears correct and also matches OpenEVSE which I have logged into directly. The OpenEVSE shows MQTT connected so that is not the issue.

openevseconnected

Any suggestions as how to resolve this.

Edit
The statement below is now untrue. Further testing the switching has been almost immediate…

As an aside one of my old DS devices sometimes shows unresponsive for over a minute or so after a change. This is different behavour to before the latest update. It always showed unresponsive for probably 20 seconds at the most.

If there is any way I can help resolve the OpenEVSE issue please let me know.

7

Don’t know if this is related.

Checking OpenEVSE DS on a tablet clicking off caused this error message:-

exception
exception3031Ă—1208 1.46 MB

8

I wonder if the issue is the result of having two sets of OpenEVSE inputs, one from the HTTP route and another from the MQTT route (assuming thats the case, as I’ve suggested here Device Error, I cannot edit inputs. Bit of a show stopper HELP! - #35 by TrystanLea).

If you can reduce it to the one set of inputs, hopefully that will sort it and if not we can proceed from there.

Im not sure about the tablet error that seems seperate

9

Yes I had both enabled.

Disabled Emoncms and deleted inputs no longer updating.

I also had to recreate openevse demandshaper but I am pleased to report that it is now responding!
EDIT
I spoke to soon. Having been red and apparently working I tried to set first smart charging schedule and it has stopped responding.

I don’t think I saw anywhere a reference that enabling MQTT requires you to disable emoncms energy monitoring.

In fact the screen shot in the OpenEVSE instructions show clearly both as enabled. Maybe the documentation needs a note.

I understood that MQTT was needed to use demandshaper. Is that correct?

10

The docs probably show two different servers as the target (often HTTP → emoncms.org & MQTT to a local instance).

11

Yes that is the case. The screen shot shows HTTP is to emoncms.org.

12

Is it showing as not responding whatever you do, after switching on/off/smart? Is the command getting through to the charger at all?

Just to double check , is there now one set of openevse inputs? did you delete the duplicates? is the node/device also deleted?

13

I was trying to set a charge schedule with the vehicle disconnected.

I had already deleted all the inputs that stopped updating after disabling emoncms.

I had also made sure there was only one openevse device.

As a precaution I rebooted the mosquitto server which is on a separate Pi and rebooted the emoncms Pi. Somewhere along the way these actions changed the behaviour.
I now get a response in OpenEVSE DS. If I click between Smart and Timer it responds with “saved”
If I click Off it responds with “Settings Mismatched” but I guess this maybe because the vehicle is not plugged in. I will try setting a scheduled charge tomorrow when we return from a trip out.

14

Great, Im sure I’ve seen that too, but testing just now, it seems to be giving saved on all states with the car unplugged. I will do a bit more testing in the morning. If you open your browser console window it should print the exact details of the settings mismatch, it would be useful to know what your seeing.

Otherwise it sounds like its all working ok (assuming it saves in all states when that car is plugged in).

15

I managed to set up DS to charge over night controlled by Agile rates.
Pleased to advise it worked perfectly!

Thanks for all the assistance. Its all worthwhile when you get it going.

2 Question regarding DS.

Is it now all right to us Ok to interrupt: ?

I also have a storage battery. Clearly I do not want the battery to discharge whilst OpenEVSE is charging the car. What are the MQTT messages that start and stop charging? I can trap these and issue MQTT messages to the storage battery inverter to disable discharge.

Lastly I still see the openevse Settings Mismatch.
Consistently if I click Off when car is not connected. I have not tried when car is connected.

Is this the console info you require?

ds error

16

Great!

Yes, and schedules can now be set at minute resolution if required.

Here’s the device class that sets the MQTT messages that relate to on,off,timer etc, in short:

openevse/rapi/in/\$ST (set timer)
openevse/rapi/in/\$FE (enable)
....
openevse/rapi/in/\$FS (stop/pause)

thanks, hmm looks like the demandshaper thinks its off but the charger still thinks its in timer mode. I will see if I can replicate here.

Thanks a lot

17

@TrystanLea

I noticed that during an update the other day there were further changes in DS.
Sadly I think they have had the effect of making changes to any of my DS devices report unresponsive more frequently.

I do seem to get a better response if I switch away from DS to say APPS and back to DS.

Could it be an MQTT issue? I have often wondered if there is a practical limit to connections and topics in Mosquitto on a Pi. I have something in the region of 40 end points all connected by Wifi or internet spread over 4 separate buildings many reporting at 10 second intervals.

DSunresponsive

18

Hi @TrystanLea

I am still having this issue. All I see in console is the unresponsive count number just increasing.
Its a shame because it stops me using OpenEVSE and other devices efficiently. At the moment I am using DS to establish charge time and manually setting timer in OpenEVSE. Not a big issue at the moment as due to Covid I am only charging once a week.

However I would like to get to the bottom of this. I realise it must be something in my setup if you can’t replicate the issue. If there is anything I can do to trace the issue let me know.

Are there logs of DS activity that might provide a clue to what is happening?

** Edit **

I left DS running. After 168 attempts it finally got device state matched.
However it surely it should not take this long and this many attempts?

Matched

19

Hi @TrystanLea

Further indication of the issues I am having with demandshaper. Console display, hopefully might help. Are we just looking at a timing issue?

dsunres
dsunres588Ă—713 81.6 KB

20

Hello @ian sorry for the delay. How quickly does the unresponsive count increase for you? 588 unresponsive messages should take ~30 mins (3 seconds per attempt), is that what you are seeing?

If youd be happy to try a minor code change you could experiment with longer timeouts here
demandshaper/MQTTRequest.php at master · emoncms/demandshaper · GitHub

perhaps to 5 or even 8 seconds?