More options for scheduling/fetch interval

[Grizzelbee]

I like to do two different things with this adapter:

• Monitor the current power consumption constantly
• fetch once every day the current total power consumption value and store it in the database at the best every day at the same time

Monitoring the current power consumption works currently perfect so this is no issue.

Currently I have two instances for that:

• instance 0: Monitoring with an intervall of 25 seconds, storing the current power consumtion
• instance 1: daily fetch with an interval of 24 hours, storing the total power consumtion

Using two instances is fine for me, but I like to have the opportunity to define a fixed time for the data pull, like:

• every day at 23:59
• every last day of the month at xx:xx
• every first day of the month at xx:xx

to summorize: simple cron scheduling.

[Apollon77]

Two instances accessing the same serialport? This will pot overlap here and there and you miss a value for one ... This is general is no good idea.

I could imagine an "update "state that triggers to query "now" (if not currently already a data query is in progress") ...

[Grizzelbee]

I could imagine an "update "state that triggers to query "now" (if not currently already a data query is in progress") ...

Okay. Fair enough. But how do I achive my goal in that case? How do I store the current power consumption every 25 Secs and the total power consumption only once a day when using only one instance?

[Loenne83]

I could imagine an "update "state that triggers to query "now" (if not currently already a data query is in progress") ...

this would be a duplicate of #308.

Okay. Fair enough. But how do I achive my goal in that case? How do I store the current power consumption every 25 Secs and the total power consumption only once a day when using only one instance?

Fetching data every 25 seconds will end up in the same time on the next day. So you will need to get the value at the desired time out of the variable when the value was fetched. Example:

Adapter gets data at
00:00:00 --> save this value separately
00:00:25
00:00:50
[...]
23:59:10
23:59:35
00:00:00 --> save this value separately

[Grizzelbee]

@Loenne83
Hmm. Not really sure if we talk about the same issue.
What I like to achive is:

1. Save the current power consumtion (in Watts) every 25 secs. to see the power consumtion over the day to find peeks.
2. Save the total power consumption of the smartmeter (in kWh) at the end of every day (as close to midnight as possible) for two reasons:
   2.1 to have the ability to reconcile the invoice of the provider and
   2.2 to calculate the difference of two days since it's the total power consumption of the house for one day

So I like to store two different values in two different intervals - since I don't want to store the total (kWh) every 25 secs. which is pretty useless.

Any way to achive this is fine for me.

[Loenne83]

@Grizzelbee
I was thinking about that also, but at least in my case, that adapter always fetches both data points when you read out the smartmeter. If you save the individual values each 25 seconds or only once a day in a separate database this is up to you...

In my opinion, there is no way to let the adapter only update the value for current consumption (W).

[Grizzelbee]

As discussed with @Loenne83 bilateral via chat:
The best and most flexible solution would be to get an independant CRON and, since it's more resource friendly, an interval in addition for all 4 relevant values:

• Bezug Total (kWh) - Total power consumption
• Aktueller Wirkbezug (W) - current power consumption
• Einspeisung total (kWh) - total power delivery
• Einspeisung aktuell (W) - current power delivery

[Apollon77]

@Grizzelbee What does your post mean? I do not get it? There is not way to just get some values and others not

[Grizzelbee]

@Apollon77
Sorry for the confusion - was a bit to short to understand without context.

The Idea was to have a table in admin with the ability to add as much entries as needed by the user.
Structure might be like this (just a quick sample):

Having this every user will be able to schedule whatever he likes.
And: Yes - I'm aware that you need to poll the smartmeter every time and always get the whole datagram - containing all values.
But depending on that config you only update the selected values and ignore the unselected.
With this in hands everyone will be able to use the standard DB storing methods for data points without the need of scheduled workaround scripts to double the values somewhere in 0_userdata to get them written to the DB in the needed interval there.

This will be the most flexible solution.

Hope I made myself clear now.

[Apollon77]

@Grizzelbee Yes I now understand it but I really have to decline this. I will not add such "veeery special and custom complex stuff" to the adapter which is interesting for a clear minority of users. I'm a fan of keeping data provider adapters as simple as possible (the whole protocol stuff is complex enough) and I like to use the power of ioBroker ecosystem for such custom requirements.
In german: I hate "Eilerlegene Wollmilchsäue" ;-)

I would maybe think about enhancing the idea from above and not only offer an "update now" state to trigger an update, but also offer an "updateNow" message that returns the just queried values additionally as json in the answer. With this you can write own scripts to do whatever you like with the data and get "the data" back from "that update cycle" without the need to add "once subscriptions" (btw is another option to achieve your goal with just the update state).

[Grizzelbee]

@Apollon77
Fair enough.
But we have a different understanding of an "Eierlegende Wollmilchsau". For me it's a non directly related feature overload in this context (radar2 adapter as an example - it mixes non related things in one adapter).
My proposal was only the most flexible scheduling config to write the values to the DB directly where they occur. Because I hate redundancy as much as you hate "Eilerlegene Wollmilchsäue". In the best case the config contains only one line saying: update all values every 60 secs (just like today) - but the user has the ability to decide. Nothing more, nothing less.

The need to write, schedule and maintain scripts that read a value once a day (or whatever scheduling) only to get it written to the DB in the needed interval does much more harm to the entire system than an adapter that has a flexible scheduling config.
But ... since I don't have to write it - I don't have to decide. All I can do is making proposals.

Btw: What is that mentioned "once subscriptions"? Never came across with that.

Btw-2: Your solution with that triggers and messages sounds much more complex to me than the scheduling stuff. 😉