Big progress now. I have the ios app running on two iPhones and two iPads and it appears to be working very well. Tomorrow we may see some sun so I shall have anoter play then.
The ios apps are very good - well done!
1 Like
Good news! Using the ios Emoncms app I can now see 3 Apps - MyElectric, MySolar and my SolarDivert. The data for all three looks to be correct.
Bad news - the OpnenEVSE charge rate can be controlled OK using a browser through the local IP address but when switched to Eco it sits at the manual charge rate whatever PV happens to be available.
Also, accessing the emonpi directly from the desktop the OpenEVSE App gives this result:
Hmmm, since posting the above the OpenEVSE charge rate has dropped to 6A. Maybe I am not giving it enough time to settle? I hope to look at this some more this afternoon.
The problem with desktop app is unchanged.
That looks like it might be a slightly different manifestation of an old issue with apps that i thought was fixed. It maybe that you do not have enough historic data and that too will be ok after you have 24hrs of use_kwh.
It looks as if you are correct Paul. The problem simply disappeared.
I need to do some more testing to see what other problems remain. The mobile app running on the iPhone and iPad is looking really good.
Perhaps you could help me understand Glyn’s suggestion for giving the OpenEVSE priority when surplus PV is available. He said:
In order for the OpenEVSE to take priority over your PV diverter I would recommend using solar PV gen rather than grid-import-export to inform the OpenEVSE divert. To do this you will want to enter into the solar PV gen MQTT topic in the OpenEVSE setup emon/emonpi/power2
I have no idea what that means maybe you could explain for me.
As I previously said, I’m not that clued up with the EVSE stuff so I do not know for sure. But I’m guessing his suggestion is essentially to change the source of the value that the EVSE uses to track your energy “available for EV charging”.
When you tell your EV to track export (which I guess would be the default) you will end up with the EV and the “MartinR” diverters battling for the excess and due to the way the “MartinR” diverter works i thinjk that might prevail so only once your DHW tank is up to temp or whatever dump loads you have, are finished would the EV be charged.
If I understand correctly, Glyn’s suggestion is to tell the EVSE to track your PV rather than the export. The result there, if I’m not mistaken would be that the EV could consume all of your PV leaving you to import for essential consumers.
If the EV is to have top priority over excess PV before the MartinR diverter gets at it, but without costing you import. I think you need to create a “available_excess” feed which is pretty much PV minus regular non-diverter consumption. and “publish to mqtt” that value for the EVSE to use. Then whatever the EV doesn’t use is “mopped up” by the diverter by closely tracking the grid import/export.
Which ever feed you chose to use, you need to navigate to the EVSE settings and add the MQTT topic details there. I’m not yet sure that my assumptions above are correct and I’m really unsure about the polarity/signage of the feed you need to track because ordinarily when monitoring a grid cable, export is negative, conversely PV is a positive so I’m a tad confused about whether you need to track a positive or negative value. It’s easy to change sign, I just don’t know which it is you need.
I hope at least some of that make some sense to you. You were warned EV isn’t my strong suite 
I answered a similar problem here not all that long ago. I can’t remember what the other conflicting system was - let’s call it “EVSE” for the sake of the explanation.
The secret is which unit sees what as the household load and the grid power. If MartinR’s (or for that matter Robin’s or any other) can see the EVSE as part of the house load, then it will defer to the EVSE. But the EVSE must not see the dump load. That was cured by running the dump load wire backwards through the EVSE’s c.t., so that the dump load current flowing in the main incomer got subtracted inside the EVSE’s grid c.t.
I don’t think the EVSE works like a diverter as such. It doesn’t have CT’s it is dependent on you feeding it a value stream via MQTT. Usually it works on export, so it would be a low priority, or as glyn suggests use PV, but that would give the EV priority over all consumption, not just excess PV, as it will try to feed all the PV to EV even if you have every consumer in house turned on.
I just found this page all about setting up evse and there’s a section on this very topic. It seems to also suggests a synthetic feed from emoncms.
This all makes some sense, the bit that gets me is the change in sign. If the choice was PV or EXPORT feeds (where both are positive) that would make more sense to me. The fact it’s grid (with neg export) or PV throws me. It can’t rely on absolute(grid) as it wouldn’t be able to distinguish import from export.
Ahh! looking at the screenshots there seems to be 2 topic fields so maybe (basically) one is for positive and the other for negative ? It’s not clear to me if that is an either/or selection or both can be used. One is greyed out in the screenshot.
Brian, I just spotted this notice on the same link as given above
The decision was made not to pause charging if generation current drops below 6A since repeatedly starting / stopping a charge causes excess wear to the OpenEVSE relay contactor.
Agreed, but there’s enough similarity in the operating modes for it to suffer the same sort of problem - competing with the diverter for the available power.
From what you’ve written, it would seem to me that MartinR’s diverter needs to send its diverted power to emonCMS, there subtract it from the grid power, and that way (provided the EVSE appears as a house load to MartinR’s diverter), the EVSE should get priority over the dump load.
Thanks guys. I shall wait for @glyn.hudson to comment and see what he was suggesting that I should do.
Yes, I had read the statement regarding a 6A minimum thanks.
It appears that when I connect the car to the charger it defaults to manual mode and starts to charge. This is probably by design but I prefer it to be in auto mode so have to get my 'phone out and change it each time. Not a big deal though.
I have updated the system diagram to show the new position for the Emonpi CT as suggested by Glyn
The obvious problem is that only grid power is detected and shown on the display. Power coming from PV is not included. I am not sure if this is what Glyn intended or not.
The first thing to check is that your OpenEVSE is getting the correct MQTT feed for your solar PV? If working correctly you should see the current real-time output of your solar PV gen or grid import export (which ever you are choosing to use) on the openevse webpage. Next to the real-time figure should e the calculated charge current eg 1.7kW = 7A
Please could you post a screenshot of your OpenEVSE main web page and ‘Services’ page, so I can check the settings.
On the services page MQTT should say “Connected: yes”
That looks correct.
Assuming your emonPi CT1 is clipped round your grid import export and the reading is positive import and negative export.
Could you post an image of the main openevse web page showing the current value of your Grid Import export?
However, you mentioned you have a solar PV diverter. The issue is that the solar PV diverter will react faster than the the EVSE and well steal any excess power before the EVSE. I’m assuming this is not what you want? You will probably want to prioritise EV charging over hot wate heating?
To prioritise the EV over hot water I would recomend that you divert the solar PV directly to the car rather than just excess. To do this you would change need to change the solar PV divert settings to remove the Grid I/E then in the solar PV gen box (which will now be un-grayed) enter emon/emonpi/power2
2 Likes
I’ve said it before and I’ll say it again - the design of eco mode is not optimised for a high capacity car like the Model 3 and is definitely not as automated as it should be. I would very much like for it to read the state of charge from the Tesla API and then make a decision on whether or not it should pull from the grid. Alas my programming talent is such that the most I can do about it in the near future is complain on this forum.
1 Like