Not quite sure what data feeds I would put in some of the categories when setting this up within emoncms.org …
#1 House or building use in watts - should this include solar panel production (which would reduce the kWh value) and/or the diverted power to the immersion (which would increase the kWh value), or should I create a new Feed that captures everything other than the solar panels & immersion divert instead?
#9 Cumulative grid import in kWh - how would I calculate this? I have x3 CTs attached to the x3 wires coming out of the box that is immediately downstream of the main meter; should I just create a Feed that is the sum of these three Inputs? Obviously this would include solar panel activity and immersion diverted power too.
Yes, sum all three (and possibly the 4th in the office too IIRC?) this gives you “grid” which will indeed go positive for import and negative when exporting during times of excess PV, so you add a “allow positive” process and log that to a feed as “import” and then use a power to kwh for “import_kwh”.
I am having some issues with consistency across a dashboard, an iOS MySolarDivert and a macOS MySolarDivert. See the attached image which shows all three side by side.
Why would the Solar be different across the two apps? They are using the same Feed. Why is Solar showing positive in one, and negative in the other?
Is there any reason why the “field input names” across the two iOS / macOS MySolarDivert are different? I’d like to think that I have used the right ones, but maybe not.
One other thing that is worth mentioning; within the Inputs feed the “Updated” column data should show a maximum of 30 or 10 seconds; I am finding that one EmonTx in the house and the emonPi in the office report in a timely manner, but a second emonTx in the house, and an another emonTx in the garage often show delays - often quite lengthy - but I can’t work out what causes the drop outs?
There is very little there for me to draw any conclusions and the inconsistencies are too numerous for me to try and understand/explain each in turn.
I would recommend starting off looking at the feeds page, forget about the dash’s and apps etc for a moment and just look at the feed data for a sanity check. For example looking at the dials on the dash on the left (i do not know which feeds drive these but taking them at face value) if import/export is -0.2kW that is 0.2kW of export, you are only generating 0.4kW so that leaves 0.2kW consumption. and yet your consumption sub-total is 1.2kW, where is that extra 1kW coming from?
If your data is coming from multiple devices it is essential they update together to generate an accurate report so you do need to look into why those devices are not posting. are all the emonTx’s using emonESP’s? have you tried moving them slightly or checking the wifi signal level at each location with your phone? Are the dubious devices near other electronics, mains wiring or behind metal or thick brick walls etc etc
192.168.1.40 … x1 emonPi with two Office CTs (Office and Barns), posting to emonCMS
192.168.1.21 … x1 emonTx/ESP8266 with two House CTs (Old House, Extension), posting to emonCMS
192.168.1.27 … x1 emonTx/ESP8266 with three Garage CTs (Panels, EVSE, CU), posting to emonCMS
192.168.1.38 … x1 emonTx/ESP8266 with one Loft CT (HW tank), posting to emonCMS
In order, these four are reporting in emonESP RSSI dBm of -63, -63, -67 and -77 respectively. All are connected to the same SSID, albeit via different access points. Wi-fi coverage throughout the house is generally more than adequate; are dBm in the range -63 to -77 good bad or indifferent?
In order, these four are reporting in emonESP “Connected” of Yes, No, No, Yes right now, but this doesn’t seem to be consistent over time.
Within emonCMS.org Feeds, the Updated figures are 22s ago on the emonPi, a range between 13 mins ago and 18 hours ago for the House emonTx, 4 mins ago in the Garage, and 7s ago for the HW.
Clearly this is wrong, but I am at a loss as to know what is causing the drop outs. I have tried unplugging the EmonTx’s for a few minutes and then powering back on, but that doesn’t particularly cure anything.
Turning the house emonTx off/pause 30 secs/on and the inputs & feeds then renew as intended. Doing the same in the garage didn’t make any difference, but going in to emonESP, re-entering the write API key and then restarting it via the software did work - the Connected No turned briefly to Connected Yes, some “messages” were sent/received(?), but then shortly afterwards reverts to Connected No.
Which makes me think perhaps it is a wifi issue? The house is reporting -66 dBm, but the garage is reporting -56 dBm. Is there a threshold here - or what should one want it to read?
I recall seeing that same behavior. In that particular instance, it was caused by a password
that contained a + and a . character. (plus and period) Once I eliminated them, (both characters)
it started working correctly.
Your signal levels are OK. Reliable operation should be obtainable with signal levels down to
at least -90 dBm as the radio has a Minimum Discernible Signal level of much less than that.
it discusses intermitant emonESP’s and a possible issue from the PSU plugs not quite fitting and also explains “psent” and “psuccess” which might help with debugging.
It also mentions a wifi issue that I experienced (not with emonESP though) due to using multiple access points with the same SSID and PSK.
Thanks Bill; whilst long and complex, none of my passwords contain non alpha-numeric characters, so that isn’t the issue, but the number of same named SSIDs might be, so I have ordered a new access point. I’ll give it a unique SSID, and place it nearer to the ESP8266 as well.
Thanks Paul - that thread was very interesting. It does look like my psent and psuccess data could well be the issue. Looking at the inputs of my three emonTx, they are …
Whether the garage problem is signal strength (see earlier reply to Bill) or a power issue as described by Ian in your linked thread above I’m not sure - but will work on both when the new access point arrives on Wednesday.
