Done that:
1 Like
Looking at MartinR’s code for “emonTx_Solar_Controller_Temperature_PLL.ino”,
does not necessarily have to be the case if Brian’s sketch uses the same `rfm_send`` function. It is a relatively simple job to change it to pass in the NodeID as a parameter so that the diverter could have a separate NodeID for each payload.
(It is only a limitation of JeeLib that fixes the NodeID at startup for evermore.)
Whilst I don’t know for sure, reading between the lines I believe it does have to be the same as the remote is only set up to receive from node 10. Having said that I also believe that the “extra” payloads are most likely identical to the regular payloads so IF the extra payloads get picked up it wouldn’t matter.
But as I said, it is better practice to properly define the node’s length anyway, the emonSD’s default node 10 definition is wrong to be so vague. For the last week Brian’s diverter has been partially accepted as a valid emontx payload, that wouldn’t have happened had the original node 10 datacodes been defined in full.
It may be useful to include a copy of Brian’s version of MartinR’s controller software:
eMC_remote.ino (30.8 KB)
Thanks Brian.
That removes a few assumptions:
The ‘normal’ and the ‘extra’ data payloads are identical.
The ‘normal’ message is sent every 3 s, the ‘extra’ is sent whenever the external load is switched on or off. (That we knew).
Paul:
My point was that when you are not constrained by JeeLib, it’s possible to send from two NodeIDs. Whether that is desirable or not depends entirely on the prevailing conditions.
Knowing Martin’s sketch fairly well, having based the 3-phase sketch on it, in the circumstances I’d probably have sent two separate payloads from two different NodeIDs, so that the ‘extra’ message wouldn’t affect the timing of the main data recorded in emonCMS; neither would the remote diverter need to handle the normal payload, other than to reject it if it’s not relevant to it.
I purposely did not comment about using the default vague node definition. Its advantage is it’s vague, thus it allows limited changes without having to edit the definition. Its main disadvantage too is it’s vague, because it allows unwanted data through so that you need to edit the node’s definition to block it. Personally, I’m with you here - a full and complete specification removes doubt, confusion and ambiguity, and on balance that is a good thing.
If we ignore the MartinR diverter the system must look the same as any other OpenEVSE with solar PV. There must be many others in this community who have addressed the problem without simply dumping all PV to the car. I wonder if one of them could chip in and offer advice?
Indeed it would, I thought it was understood that PV minus USE(excl EV) was the answer, your very first diagram showing both the diverter and the emonpi would have worked well. As pointed out at that time the only issue was that the MartinR diverters would take priority (if enabled) so ignoring the diverter loads, there is no problem!
If you are un-willing to put a CT on the EV (best option) or move the EV back to HB1 (next best thing) then yes it could, as a last resort be calculated from the values returned from the EV, but do not expect it to be as accurate. And if you do turn on the diverter, both DHW tanks need to reach temp before the EV gets a look in.
Have you put a CT on the main diverter load?
Since the diverter can be switched frequently (and I’m not talking about rapidly like a induction hob, I mean it’s status can change often) and there is a spare channel on the diverter which is “continuous monitoring” unlike the emonPi. That’s where I would connect the diverter CT.
With a CT on the diverter and a CT on the EV in addition to the existing Grid and Solar CT’s we will be all set to start talking about input processing, but until you have credible values for EV and the main diverter there is no point looking at input processing as you simply cannot manage what you cannot measure.
I don’t think you previously answered my question about how the battery storage charge/discharge fits into the equation, but if you do as suggested above, there is the 2nd CT channel on the emonPi available so it could be taken into consideration (or maybe even controlled) if needed.
There are numerous things you can explore (or not) to improve things like using http rather than mqtt to retain the integrity of the payload and timestamps or changing the update frequency of the diverter (and remote) to 5s or 10s to better fit with emoncms feed intervals and reduce the rounding error from integer timestamps. But everything revolves around being able to separate the different loads or perhaps more accurately the different levels of diversion at least.
I think we’re getting a little side tracked by this. I know it’s possible, I have suggested it myself on many occasions, you and I have even discussed it previously. There aren’t really any constraints by JeeLib, the RFM2Pi FW can change node id at will and in fact in one of my dev jeelib interfacers for emonhub, the node id could be changed to transmit as a different node just to serve the emonGLCD’s that were already in circulation set to receive from a fixed node id. Don’t forget the emonpi reinitialises the rfm module every 60s just to avoid hanging! (or at least it used to, I lost track if that “fix” was in or out).
I took the prevailing conditions to be that the diverter is already in service, I wasn’t considering re-writing the diverter sketches.
As do I, all my emonTx sketches are based on it and my own home is both monitored and has a diverter load controlled by one too.
and I might well of done something similar, but the existing remote sketch also checks for a regular update from the main diverter and if it hasn’t been updated in the last 5s it switches off, so an “on change of status” payload alone will not work unless the “extra” payload is also sent regularly regardless of state changes or not.
[edit]
Just checked and it’s still in. And checking has jogged my memory, from private discussion back in June 2018
I have a bunch of different problems I am trying to fix and can only devote limited time to this one but I am very grateful for all the effort you chaps have contributed.
As a stop gap work around I decided to switch off the main tank that MartinR controls and revert to the original OpenEVSE configuration with the SolarPV topic set to openevse/solar. This should give priority to heating the DHW tank and the house with any PV power remaining being fed to the car.
Unfortunately, it no longer regulates the power to the car but simply cranks up to 32A irrespective of the available PV. The wiring is as shown in version 6 above. Is this to be expected in view of the changes Paul asked me to make?
I think some confusion may have crept in, I don’t think openevse/solar is a valid mqtt topic.
You haven’t implemented any of the physical changes I suggested and simply defining the correct node names and datacodes in emonhub.conf will not have impacted anything except the diverter data being correctly labelled in emoncms.
With the risk of sounding like a broken record, a pv or solar topic will cause the EV charging to track only the generation with no regard to consumption as you have already experienced and any topic entered into the “SolarPV topic:” field cannot include EV to avoid a cycling action.
However if you are willing to switch off the main diverter load then you could simply put emon/SolarDiverter/Grid into the Grid (+I/E) topic: field. You cannot use the original spec emon/emonpi/power1 topic with the current wiring arrangement and CT locations you have because the “grid” (emonpi ct1) no longer includes PV since rewiring the Henley blocks.
If you move the emonpi grid ct1 (ct4 on your diag) alongside the diverter’s ct1 you can then use the original emonevse configuration (with the main diverter load disabled) but you will then be back to the emonpi CTs exactly duplicating the diverter CT’s again.
Thanks Paul I shall try the ‘emon/SolarDiverter/Grid’ into the Grid topic tomorrow when some PV is available. Presumably I leave the SolarPV-gen topic blank?
I cannot :
Assuming you mean moving CT4 downstream from the house CU ie on the ring main that supplies the main dump load. This is not mechanically feasible.
It will help if I am better able to understand how inputs, processes and feeds work. A pointer to some instructive pages will be a great help then maybe I will stop wasting your time with embarrasingly dumb questions.
Presumably this is so that the power consumed by the dump load can be measured.
I mentioned this earlier: I think in his original design, Martin used temperature to override the control of diverted energy (therefore the immersion thermostat ceased to have a control function and became only a safety device), this enabled his sketch to (moderately accurately) calculate the diverted energy based on the triac ‘on’ times and a knowledge of the immersion heater rating and system voltage. Is it possible then to mount a temperature sensor on the hot water cylinder, read it with the Arduino that switches dump load, and radio that temperature back to MartinR’s diverter?
OK, the system now behaves as described above. The work around of turning off the main dump load when charging the car will have to suffice for the moment as I have many other things to sort out.
Curiously the OpenEVSE unit decided to sulk today and would not connect to the WiFi properly. I have raised that in another post.
There is a strange satisfaction in driving a car powered purely by sunshine. It’s similar to the pleasure of taking a daily shower heated by PV but somehow even better.
Anyhow, thanks again guys.
1 Like