OK, Paul. Thank you very much for the help. We are operational again. Yes, I did try flushing redis, but I must admit I don’t know exactly what that means. But a reboot of the emonPi, ie. I pulled the power plug, did the trick and yes 13.6hrs of data is now missing. As the emonPi LCD has shown updated data the whole time, I hoped that it would somehow magically end up in the database. No such luck.
At this point, I would ask for help in understanding the concept of virtual feeds, how to use them and what they are for? And the same could be said for the process lists, Is there any succinct documentation? I have many issues that I need to resolve to proceed with confidence.
I got myself into this mess, by trying to create a virtual feed that summed the two Line feeds to provide the total energy consumption (W), not unlike the total power feed (KWh). I don’t recall how I failed, I was simply playing around, confident that it would be simple to recover from any mistake.
The processes that are attached to the various [node][keys] of the input panel are minimally documented in the setup screen when you are attaching a new process. I do not understand some of the terminologies. ‘UPSERT’ (?) for example. I would like to have feeds of total power and total energy consumed, for instance, that reset to zero at a specified scheduled time. I would also like to be able to generate a feed of the accumulated power cost, that resets to zero on a monthly basis, and is based on the scheduled rates in my locale. I sense that all this should be possible, but I don’t want to get into another mess like I just got out of.
Calibration is another issue. I understand that I can use a simple multiplication factor to scale the power1 input before it is logged. This works but needs to be done as well to the power2 input and power1pluspower2 input. But the scaling is not reflected on the LCD display of the emonPi. It remains unscaled. To achieve that, I had to edit the scaling numbers for the emonPi in the emonhub.conf file as below:
nodename = emonpi
[[[rx]]]
names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulsecount
datacodes = h, h, h, h, h, h, h, h, h, h, L
scales = 1.093,1.093,1,0.01093,0.1,0.1,0.1,0.1,0.1,0.1,1
units = W,W,W,V,C,C,C,C,C,C,p
This is where I am right now. The scalar for power1pluspower2 remains in the process list for that input. The value 1.093 comes from the measurement of AC voltage at my panel compared to the value that the emonPi displayed. This is nearly the value of 120/110 (1.0909). I recall reading somewhere on the forum that these scaling factors were not the intended place to calibrate the readings. But I have found no other way of making the emonPi display and database be consistent with each other. I would have thought that once the VRMS measurement has been calibrated, then the power measurments should follow from that, since the power is simply the product of the voltage and the current, as measured by the CT’s. There is probably something about the architecture of the system that requires this value be entered in multiple places. And, this would be a design error, in my opinion.
My apologies for this tour-de-force and again, thank you for the help. You seem like more than an interested, helpful 3rd party. Are you more deeply involved in the OEM project? I don’t necessarily expect you to answer all these questions. I had to get it out. If you feel it should be posted elsewhere, I will do that.
