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?
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.
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).
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?
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
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.
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?
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?
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?
Delete Found it
Hi @TrystanLea
Some progress. With L68 set to 8 seconds I can control 3 of the commands in DS controlling OpenEVSE.
On Smart Timer. They all return SAVED.
However Off returns openevse Settings Mismatch.
EDIT
If I switch direct from On to Timer that also returns what appears to be a permanent Mismatch.
I can recover the situation by clicking Smart which returns Saved and then I can click Timer which will then return Saved.
I have tried this maybe 6 times always with the same result.
Thanks @ian
Did you get the fixed timer implementation in the recent update a couple of days ago? When did you last update the system?
Im not sure about the off settings mismatch, what happens if you click between On and Off? does it still suggest in the console that the openevse setting is timer ?
Updated this morning.
On > Off openevse Settings Mismatch consistent as far as I can tell.
Off > On respones varies.
Any Command > Smart seems to recover situation with openevse Saved again consistent as far as I can tell.
Console from On & Off
Thanks, is the car plugged in? not sure that it should make a difference but I think @jpalo did see an issue with this. I cant seem to replicate.
Do you get settings mismatch here as well? what does the console log say?
Specifically Off > On > Off
On Saved
;
Car not plugged in.
Will plug in next lull in Rain!
OK
Car plugged in.
No change as far as I can tell.
Starting with DS OpenEVSE off.
Off > On matched
On > Off mismatch with one unresponsive
Interesting that it seems to think its in timer mode when its off… I wonder if there is a firmware difference between my OpenEVSE and yours… I seem to be running v2.7.4, latest is v2.9.1 by the looks of it
I’ve updated to the latest firmware on the OpenEVSE and it seems to still be working ok Tags · OpenEVSE/ESP8266_WiFi_v2.x · GitHub
Mine is ESP32 I think only 8 weeks old.
Powered by OpenEVSE and OpenEnergyMonitor
Version: V3.3.1
