The rule should sum up all values, which track my PV system, and message me then.
First off, i devide the sum by 58 … That’s simply a number i found by try and error comparing the calculated sum to the real number i can see on my PV system’s display. Indeed, i don’t know why i have to do this.
And then i devide it by 1000 to get kilowatts instead of watts, wich is easier to read in the end, as the calculated number has like 12 digits and I wasn’t able to script something like “show me only 4 digits”, or “round to hundredths”. Maybe someone can give me a hint on this.
The first real problem is: the rule is triggered twice, whiche makes no sense to me, as astro.dusk should only fire once a day … For me it was yesterday at 8:15 pm (nautical twilight, which is wrong) and 9 pm (astronomical twilight, which is right). Is this a bug? Or do i miss something?
The second problem is: the calculated sum at these two times is different. Not only slightly different, but obviously one is totaly wrong.
Like first one gives me around 2200 watts, while 45 mins latter i get 1400 watts. So indeed the number is not even rising, where you could assume something is added to the actual sum, but the number is randomly higher, or lower …
In the astro docs you will see that the trigger channels have multiple events:
Trigger Channels
Only these can be used in rule triggers as shown below. Note that they have their own offset configurations that are independent from offsets configured on the start or end times of e.g. the rise or set channels.
So without specifying which event you are interested in your rule will trigger at both the start and the end of given time period.
In the tigger configuration for the rule you need to add either START or END to the Event field:
As for the incorrect values, it’s been so long since I’ve used dsl, I can’t really help there other than to say are you sure that the item you’re using is not directional? The value would certainly drop if you’ve got negative values during the later parts of the day if this is a net consumption value and not a raw production value.
Another thing: Please be aware that W and Wh are somehow independent values, you can’t simply add power values and get energy, you’ll have to know the time factor. (pretty sure this is the 58… it’s very likely that it should be 60, then your power value would be the average power for one minute).
What kind of solar inverter do you use? Most of them do provide energy data as well as power data.
Thanks, this seems to be the point i was missing. The end of nautical dusk is the beginning of astronomical dusk.
Writing the rule i once added “start” as the event, but this lead to the rule never been triggered. Then i removed it, and indeed since then it was triggered twice. Yesterday i added “end” and in the eventing it was triggered once, as it should be.
So this one is solved
The values are indeed all positive. The item only registers gained energy and there should be no negative values.
@Udo_Hartmann
Of course you’re right. Watt desribes the power, while watthour describes the energy.
For the sake of simplicity, let’s assume that the factor is a smooth 60.
When i have to devide the calculated sum by 60, this logically means, i get 60 values per hour. But this is simply not true, as when checking the records i see an update every 10 seconds. That’s what i am curious about.
And what makes me even more curious: the calculation is exactly the same, still i get totaly different values, while the time defference between the calculations in 45 mins and the value technically can’t get lower while time passes, but it does.
PS: i am using a hoymiles inverter with openDTU attached.
But i did not connect openDTU over MQTT, instead i am registering the energy / power through a smart plug, which is connected to OH.
May I ask why?
And even if not using data from openDTU, the smart plug should also give energy data.
And you are sure that all this data is persisted? Which persistence service do you use?
rrd4j for example will give false data, because of the granularity of data, see [SOLVED] RRD4J and Granularity / Number of Datapoints - #2 by opus for details. This would also explain why 45 minutes later you lose a third of your energy, simply because there are less datapoints to be summed up.
Indeed i never tried connectint MQTT to openhab.
All things i have run either over zigbee, or over wifi, like my smart plug. It’s a TP-Link HS110. It can report currently power usage and total energy usage, where people here in the community already telling not to use this value, as it is very incosistent.
In fact i’m using the default persistance rrd4j.
I begin to understand what’s happening there…
While i request data from around the past 21h, rrd4j will reach out for the 2nd archive, which hold up to 1440 datapoints for last 24h (one point per minute), BUT because it request 0:00am to (at this moment) 9pm i will ‘only’ get 1260 datapoints and this value will vary day by day, as the time i request the data also vary …
So, when i got this right, i will have to adapt the “correction factor” to the amount of data points, which i could calculate pretty precisly when i count the minutes from midnight to the point of time i request the data.
Or simply install mosquitto (free of charge, easy to use) and use mqtt to get the real data. If you are using openHABian, there is even an option to install mosquitto.
