I have an openevse charge controller and a Martin Roberts based energy diverter.
The system has worked brilliantly for the last 9 years or so but recently the energy diverter had a problem which required switching it off to investigate. While the power to the diverter was off, I noticed that the car had stopped charging. When I checked the openevse app Self Production feed I found it was set to ‘emon/SolarDiverter/Grid’
Clearly this is not ideal but I can’t figure what feed to replace it with so the system will charge the car even if the diverter is switched off.
Any advice will be much appreciated.
With the openEVSE, in the web control page don’t you just slide the toggle switch from “auto” to “manual” charge mode when you want a constant power sent to the car?
I mean, I don’t think you need to have an alternative control signal while your diverter is not available.
Thanks David. To be clear, the ‘Enable Charge’ button which overrides the ‘Eco’ setting works fine at all times.
My problem is the ‘Eco’ setting which also works fine but only if my water heating energy diverter is switched on.
The OpenEVSE charge controller should be working independently of the diverter. Other people with an OpenEVSE but no diverter do not have this issue.
I just need to know what feed to use in here:
I had an OpenEVSE for many years (but I no longer do).
When I did, the solar divert MQTT control for the EVSE was published by an emonPi which made a feed using a c.t. on the grid cable at the utility meter.
Do you have any kit that can fulfil that role?
Yes, I have a rpi which provides real time data:
As I recall, I made a new virtual feed which was solar generation minus house consumption minus some constant ( perhaps 100W) in order to give some margin to avoid import.
Then I published that to MQTT.
Readers: Please note that it is no longer possible to publish to MQTT from a Virtual Feed. It is only possible via the Input Process List on the Inputs page. (Moderator - RW)
Here’s a screen grab of how that feed looks today - but line #2 has been changed along the way probably at the time when it was being abandoned. But it might show you the shape.
There may be some further pointers in MQTT — OpenEnergyMonitor 0.0.1 documentation
Sorry I can’t be any clearer.
I’m in no way an expert with manipulating feeds like this. Do some more trial & error.
Try starting the process list with an “absolute value” set at zero?
Try using “+ input” rather than “+ source feed”?
Others with way more knowledge may chime in.
Before writing, I tried the same “absolute value” on my emonPi without issue. Adding it to a new virtual feed had the effect of changing a NULL value to zero, which I took as progress.
This might help, if you’ve not seen it:
Should the first process step be Source Feed, not + source feed? (Not that I think it should make any difference if you start with a definite value of Zero - but you never know 
.)
My understanding is, you cannot do that - maybe it has changed?
Until I am able to restore the feeds page I am stuck. Is there a reset somewhere?
I’ve done the same trying to reproduce your problem. It appears when reloading the Feeds page. This must certainly be a bug for @TrystanLea, I’ve never seen it reported before 
Thank you @Robert.Wall In anticipation of a request for version info:
Services
emonhub : Active Running
emoncms_mqtt : Active Running
feedwriter : Active Running - sleep 300s 276 feed points pending write
service-runner : Active Running
emonPiLCD : Active Running
redis-server : Active Running
mosquitto : Active Running
demandshaper : Not found or not installed
Emoncms
Version : low-write 11.5.6
Git :
URL : GitHub - emoncms/emoncms: Web-app for processing, logging and visualising energy, temperature and other environmental data · GitHub
Branch : * stable
Describe : 11.5.6
Components : Emoncms Core v11.5.6 | App v2.8.5 | EmonHub Config v2.1.5 | Dashboard v2.3.3 | Device v2.2.6 | Graph v2.2.3 | Network Setup v1.0.5 | WiFi v2.1.1 | Backup v2.3.3 | Postprocess v2.4.7 | Sync v2.1.7 | Usefulscripts v2.3.11 | EmonScripts v1.8.4 | RFM2Pi v1.4.2 | Avrdude-rpi v1.0.1 | Emonhub v2.6.13 | EmonPi v3.0.3
Server
CPU : 1 Threads(s) | 4 Core(s) | 1 Sockets(s) | Cortex-A53 | 89.60MIPS |
OS : Linux 5.15.76-v7+
Host : emonpi | emonpi | (192.168.1.205)
Date : 2026-09-26 13:12:34 BST
Uptime : 13:12:34 up 1:19, 0 users, load average: 0.21, 0.29, 0.34
Memory
RAM : Used: 23.58%
Total : 922.14 MB
Used : 217.41 MB
Free : 704.72 MB
Swap : Used: 0.00%
Total : 100 MB
Used : 0 B
Free : 100 MB
I’m running an emonPi3 board on a very early RPi, but updated only yesterday. I’ve deleted all my feed files (they only had minimal test data anyway) but no change. I don’t know where the process rules are stored inside emonCMS - nothing like this is documented, as far as I know.
I’ve deleted the only process list (V1|) and it’s still locked,
This is what I see (shrunk t for readability).
I shall patiently wait for @TrystanLea
Hopefully @dmajwool does not think it’s his fault! These things happen.
I do feel pretty bad about it, but as I said I did experiment and create a new feed with those same virtual feed settings on my system first without issue.
For information, my emonPi emonCMS hasn’t been updated in years. I’ll look up the version number when I get home and edit this post.
Edit: @BrianD
Here are my versions that didn’t cause a lock-up when I made a new virtual feed as described above.
Emoncms
Version
low-write 11.0.9
Git
URL
Branch
* stable
Describe
11.0.9
Components
Emoncms Core v11.0.9 | App v2.6.6 | EmonHub Config v2.1.1 | Dashboard v2.2.4 | Device v2.1.9 | Graph v2.1.6 | Network Setup v1.0.2 | WiFi v2.1.1 | Backup v2.3.2 | DemandShaper v2.2.2 | Postprocess v2.2.4 | Sync v2.1.3 | Usefulscripts v2.3.9 | EmonScripts v1.4.1 | RFM2Pi v1.4.1 | Avrdude-rpi v1.0.0 | Emonhub v2.3.3 | EmonPi v2.9.5
This is the MQTT feed of your gird, the value should be positive for import and negative for export. Also, its important that the power used the OpenEVSE is included, I.e the CT is around the main incoming cable before any henley blocks.
It should be emon/emonpi/power1 if you’re using emonPi CT1 input to monitor the grid. If your using CT2, then you should instead use emon/emonpi/power2
See the OpenEVSE setup guide: https://docs.openenergymonitor.org/emonevse/setup.html#mqtt-setup
However, I would recommend using the PV divert in ‘Generation’ Mode rather than 'Export. In my experience it works better in the mode. You are welcome to experiment YMMV.
Can you assist in restoring my greyed out feeds as described above please? Then I can try your suggestion.