Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


  • 0

Wall Plug Power Reporting


Guest Turmoil

Question

Guest Turmoil

I have a wall plug to a single device which when on uses a fairly consistent 250W, I have a Lua scene defined that checks when power > 200W. I wish to optimize the scene invocation by adjusting settings parameters 40, 42 and 43 e.g.

  • minimum number of scene calls during power up (default parameter values allow 3-4 repeated calls).
  • minimum steady state calls

I assume the power on scenario trigger is defined via parameter 40 (Reporting significant changes in power), which I assume I need to keep to ensure a responsive automatic scene invocation.

Qu. I'm not sure how this parameter (40) works as trigger is at 80% of previous value but previous value is initially 0. I am guessing that subsequent triggers are at 80% increments. If we take the case of an initial report at 60W (say), then can I expect reports at 108W and 194W (the next would be 350W). Would this mean my Lua check for > 200W may never fire (dependent on a variable initial reporting value)?

I also assume that parameter 42 applies to the steady state scenario

Qu. Can I turn parameter 42 off with no additional side-effects? e.g. power off still detected. power consumption still reported.

 

I have experimented with this device to get automation working but I would like to understand what exactly is happening so that I can reasonably automate other devices.

 

Thanks in advance for any light or documentation references you can provide.

Link to comment
Share on other sites

10 answers to this question

Recommended Posts

  • 0

Thank you for your elaborate testing & report!

 

On 9/25/2018 at 4:57 PM, Turmoil said:

There is a delay here as the projector lamp comes on but the wall-plug reports the power hike some seconds after I see the lamp come on. It's a normal lamp so perhaps it takes time for the power consumption to rise to the next necessary reporting threshold?

I do not know the delay between the thresholds, but I do know this:

  • There is about 0.7 seconds between turn on of a load and reporting power. This might be due to the sampling mechanism, the firmware code or it might even be deliberate, because Z-Wave is not very fats it makes sense to put delays between data packets. I do not know...
  • It takes about 0.25 seconds to launch a scene

So it cannot be faster than that.

I expect, purely based on observation, varying loads get reported after 2 - 5 seconds, ballpark

 

On 9/25/2018 at 4:57 PM, Turmoil said:

Here we got 4-5 calls to the scene (as a result of major power changes) in place of the 7 calls in the test above, so some of those extra calls were likely a result of small changes

Sounds plausible.

 

On 9/25/2018 at 4:57 PM, Turmoil said:

Similarly on power off a residual power drain of 1.2W was shown instead of the normal 0.5W for the wall-plug itself.

I occasionally see this as well, but I cannot reproduce it right now

 

In code, you can always request an update, but I do not know if this fixes the problem of the "stuck" 0.5 W report. Because I do not know if this is a reporting problem (fixed by this piece of code) or a measurement error (in this case, the plug might again report 0.5X)

 

Please login or register to see this code.

 

On 9/25/2018 at 4:57 PM, Turmoil said:

The lmod time (last modified) is always 0, logical since this is the event for that last mod change.

 

Correct... But it might be useful if you start a loop in your scene. Or to check if another device was turned on X time ago.

 

On 9/25/2018 at 4:57 PM, Turmoil said:

It is unwise to prevent p42 power reporting as this impacts the HC2 power consumption reports

In some cases, it is important to reduce the number of reports.

 

I see an important issue with your code. It is not your fault (!), I think it is lack of documentation (!!):

 

Please login or register to see this code.

 

Never simply do "fibaro:call(idTestSocket, "turnOn");" because that will REALLY send a command to the plug, even when it is already on. It takes Z-Wave bandwidth and you probably over-estimate the capacity of the network. Always test if it is already on.

 

I have reworked your code a bit. Important change: I noticed, in your script, you try to control the plug that senses power. That might be OK but I think it is easier if you first try to control another device. Select a relay or a plug and change 9999 in this code to match your (second) device:

 

Click on the spoiler to reveal the code (it is a forum rule: "hide long pieces of code and pictures").

 

Please login or register to see this spoiler.

 

BTW the newer version of the FGWP has the same type of parameters (different Ids), but it is newer hardware and firmware. If you have one, or if you need a new plug anyway, I think it is worth trying one this application...

Edited by petergebruers
Link to comment
Share on other sites

  • 0

First, to answer your question, % means "with respect to previous report". So it is a bit difficult to answer without knowing the load variations. BTW you are correct, these settings can lead to "too many reports".

 

Can you please post a graph? You can do this by clicking on "consumption" then under energy "more" and then you can select that device and make a graph of an interesting period.

Link to comment
Share on other sites

  • 0
Guest Turmoil
  • Inquirer
  • Thanks for the quick response. I have attached a sample power on sequence. It's a projector that has a 3-4 second start-up sequence.

     

    From the steps in the graph I'm beginning to suspect that the plug has it's own (non-parameterized) power review frequency. e.g. If this frequency was a review every 10ms the first report would then be generated at whatever the power value was at 10ms (since previous value was 0). Perhaps at the next cycle 20ms we have increased by another 80% then another report is generated, at 30ms it may not have increased again by 80% so no report etc.

     

    Is this your understanding of how it works?

     

    The next question would be is the algorithm clever enough to always report the final steady state value?

     

    Any ideas about parameter 42? Is this just to detect small fluctuations in the steady state and can I turn it off?

     

    Thanks again for your help.

     

     

    Please login or register to see this spoiler.

     

    Edited by Turmoil
    Link to comment
    Share on other sites

    • 0
    6 minutes ago, Turmoil said:

    Is this your understanding of how it works?

    Well, the algorithm is undocumented, but from my own experience I'd say what you say is about right...

     

    When the difference is like p 42 = 15 % it sends an update asap, but with a maximum of 5 for the first 30 seconds. Those 5 reports can indeed happen very early in that 30 s interval.

    When the difference is like p 40= 80 % it always sends an update.

     

    I have never really checked this, but because both parameters specify a % I would say the "end power" can be off by as much as 14 % (because at 15% it exceeds p 42, but not below that).

     

    But there is more. You can toy with Parameter 47, Time period between reports on power load and energy consumption.

     

    For instance, if you set it to 5 minutes instead of the default 1h, you get an accurate report every 5 minutes.

     

    I advise you to toy with those parameters and make a graph to evaluate the effect. It is a compromise between accuracy and reporting frequency, but you already know that because you posted this topic!

    Link to comment
    Share on other sites

    • 0
    Guest Turmoil
  • Inquirer
  • Hi Peter,

     

    Thanks for that. In this case the final power is not a real problem I can trigger at 100W and use a global to maintain state. As well as minimizing the number of reports generated, I was hoping to manage multiple equipment with the Fibaro wall plug controlling a multi-socket then use the total power to determine which equipment is actually in use but this will probably be too difficult with all the transient reports.

     

    I'll experiment as you suggest and if I come across anything interesting I'll update this post. This, however, raises another question: can a Lua script determine the Z-wave frame on which the report arrived i.e parameter 40 explorer frame bit set, parameter 42 explorer frame not set? There is a zwaveinfo parameter for getValue I'll see what that has to offer.

     

    Thanks again.

    Link to comment
    Share on other sites

    • 0
    26 minutes ago, Turmoil said:

    This, however, raises another question: can a Lua script determine the Z-wave frame on which the report arrived i.e parameter 40 explorer frame bit set, parameter 42 explorer frame not set?

     

    Not really, but this might be useful. All values have a "last update timestamp". So you know when the last change happened.

     

    Please login or register to see this code.

    Prints

     

    Please login or register to see this code.

     

    Edited by petergebruers
    Link to comment
    Share on other sites

    • 0
    Guest Turmoil
  • Inquirer
  • Hi Peter, as you say zwaveInfo is not interesting. However I just ran a short test and got the following (unexpected result) I wanted your opinion on:

     

    Power on +secs:     0,     2,       3,        5,      26,     33,     55

    Power reported:      8,    11,    19,    131,    167,   211,   264

     

    The scene starts taking action when power > 100W i.e. 5 sends after start. The next power trigger is at 167W and 26seconds after start. That looks to me as if the event has been queued?? I have "Max running instances" set to 1 but I was expecting Fibaro to throw the duplicated events away not queue them, this is good news (for me at least)!

     

    The other thing to note is that the 80% calculation is off or we are mixing p40 and p42 triggered events. I have more to investigate but wanted to post this.

     

    BTW: thanks for the script, I forgot about Lua returning multiple parameters on a function call, I see I'll have to review the doc.

     

    Link to comment
    Share on other sites

    • 0
    4 minutes ago, Turmoil said:

    Hi Peter, as you say zwaveInfo is not interesting.

    You mean the zwaveInfo field of a device? That string contains the device type and major an minor version of the Z-Wave protocol it implements. Useful, but not in this context.

     

    e.g. "3,3,52" means type 3 (I think a routing slave, almost all current devices are routing slaves) and 3.52 is the protocol version. This tells me, it predates Z-Wave Plus.

     

    7 minutes ago, Turmoil said:

    The scene starts taking action when power > 100W i.e. 5 sends after start. The next power trigger is at 167W and 26seconds after start.

    Hard to say. You expected it sooner?

     

    9 minutes ago, Turmoil said:

    I have "Max running instances" set to 1 but I was expecting Fibaro to throw the duplicated events away not queue them

    How long does your scene run? If it does not have any sleep, I'd guess it runs in less than 1/2 second. Looking at those timestamps, you never have less then 1 second so there never is a 2nd instance. If you put fibaro:sleep(10000) you would get "max instance warnings".

     

    Not enough data, but it might make sense to have a scene with an infinite loop and e.g. sleep 5 seconds (or 2, or 60...) , then check power. And no trigger on power change.

     

    Depends also on what you want to do with that scene.

     

    13 minutes ago, Turmoil said:

    BTW: thanks for the script, I forgot about Lua returning multiple parameters on a function call, I see I'll have to review the doc.

     

    I am glad you like it. You can show your gratitude, by "clicking" the like button or up-voting the post as an answer.

     

    Have fun with home automation!

    Link to comment
    Share on other sites

    • 0
    Guest Turmoil
  • Inquirer
  • Hi Peter,

    You are correct and I take back the idea of the scene ever having being queued. There is a delay here as the projector lamp comes on but the wall-plug reports the power hike some seconds after I see the lamp come on. It's a normal lamp so perhaps it takes time for the power consumption to rise to the next necessary reporting threshold?

     

    I did some other tests as follows:

    Setting p42 to 100% effectively switching off small power change reporting:

    Test1

    Power ON +Sec:      0,      2,        5,        38

    Power reported:   7.5,   20.8,  125.1,   228.1

     

    Test2 (repeat of test 1)

    Power ON +Sec:      0,      2,         5,         37,        45

    Power reported:   7.6,   25.6,  122.7,   225.8,  494.1

     

    Here we got 4-5 calls to the scene (as a result of major power changes) in place of the 7 calls in the test above, so some of those extra calls were likely a result of small changes (I'm guessing again but with the potential to arrive out of sequence on a busy z-wave network due to the different message priorities). Turning off small changes did stop the scene being called every 20mins or so due to minor fluctuations, however the bad news is that the HC2 has no other access to power reports and where the second test caught a momentary peak at 494.1W this was never reset to the steady state just under 300W. The HC2 therfore used this 494W value in it's power consumption charts. Similarly on power off a residual power drain of 1.2W was shown instead of the normal 0.5W for the wall-plug itself.

     

    Setting p40 to 95% gave reports at 7.5W, 18.5W, 122.6W and 239.4W so almost no change there, which matches with the idea of an internal clock in the wall plug such that power usage is looked at fixed intervals and in our case the power change at these intervals is close to 100%.

     

    In my tests fibaro:getValue(idTestSocket, "power") and power, lmod = fibaro:get(idTestSocket, "power") returned identical values for power. My tests do not answer my question if one call would give the power causing the triggered event and the other the current value. The lmod time (last modified) is always 0, logical since this is the event for that last mod change. Looking at the fibaro provided power consumtion graph the power increments shown always corresponded with the scene invocation power levels.

     

    Conclusion: It is unwise to prevent p42 power reporting as this impacts the HC2 power consumption reports (at least in the short term). It may be possible to tweak p42 to reduce the number of scene calls in the steady state without impacting consumption figures but this would require case by case testing. Increasing p43 may reduce the number of reports in steady state but this was not applicable in my case since reports were already only every 20 minutes or so.

    Changing p40 has little or no effect on reporting during equipment power on.

     

    I shall stick to the defaults and code around the multiple scene calls. I would be really interested to see anyone else's results/conclusions for similar tests, perhaps on different types of equipment. My test scene was very simple but I attach it for anyone interested

    Please login or register to see this spoiler.

     

    Edited by Turmoil
    Link to comment
    Share on other sites

    • 0
    Guest Turmoil
  • Inquirer
  • Quote

    Please login or register to see this code.

     

    That looks like fun. I take it the same warnings about potentially flooding the z-wave network apply here as well?

     

    Quote

    Never simply do "fibaro:call(idTestSocket, "turnOn");" because that will REALLY send a command to the plug, even when it is already on. It takes Z-Wave bandwidth and you probably over-estimate the capacity of the network. Always test if it is already on.

     

    I did see your warning in another post elsewhere and had adapted my scenes. I should have done this one as well since I made it public, however when testing I could see the device switch on/off and even hear the wall plug give a soft click.

     

    I am marking your response as the solution so as to target your test scene. If further testing throws up anything interesting I shall try adding it later.

     

    Peter, thanks again for all your comments and help, I have learned a lot in just a few short days. Do enjoy your free time.

    Edited by Turmoil
    Link to comment
    Share on other sites

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest
    Answer this question...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×
    ×
    • Create New...