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.
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.
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?
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 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.
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 ?
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