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

Scene condition not evaluated properly after reboot


cincura.net
 Share

Question

I have this scene:

Please login or register to see this image.

/monthly_2020_09/image.png.d96069d5a6a18e0871e75b138cb0bee3.png" />

 

Whenever the HC3 is rebooted (or "restarted" as part of backup) this scene stops working. I see the button press being registered in History, but scene is not triggered. It looks like the condition is always evaluated to false or something. I have to manually, in the UI or mobile app, turn the device in condition on/off and then it's fine. I tried, as part of debugging, flipping the condition (using "Turned on") and also inverting it, but nothing works. Comparing the JSON from API right after the reboot and after the on/off dance, it's the same (except for pieces like "last modified", etc.).

 

Is this a known issue? Any other ideas what to try and where to look to get some clue? Running HC3 with 5.040.

 

 

Link to comment
Share on other sites

19 answers to this question

Recommended Posts

  • 0
On 9/1/2020 at 6:40 PM, cincura.net said:

I have this scene:

Please login or register to see this link.

 

Whenever the HC3 is rebooted (or "restarted" as part of backup) this scene stops working. I see the button press being registered in History, but scene is not triggered. It looks like the condition is always evaluated to false or something. I have to manually, in the UI or mobile app, turn the device in condition on/off and then it's fine. I tried, as part of debugging, flipping the condition (using "Turned on") and also inverting it, but nothing works. Comparing the JSON from API right after the reboot and after the on/off dance, it's the same (except for pieces like "last modified", etc.).

 

Is this a known issue? Any other ideas what to try and where to look to get some clue? Running HC3 with 5.040.

 

 

This is 'normal behaviour.' for  Fibaro: after a reset or reboot it 'forgets' the values of it's variables and the state of it"s switches. If the device in question is polled (which means it is not a variable and polling is not off for the device) the real state will be known after a few minutes when the first poll happened. If no polling occurs the only possibility for a a variable is to change it's state BY A SCENE (so, NOT mamually) and, for a device, to toggle it's state and this can be done  manually as most newer devices will automatically report a CHANGE of their state to the gateway

Edited by wienog
Link to comment
Share on other sites

  • 0
  • Inquirer
  • 6 minutes ago, wienog said:

    This is 'normal behaviour.' for  Fibaro: after a reset or reboot it 'forgets' teh calues of it's variables and the state of it"s switches. If the device in question is polled (which means it is not a variable and polling is not off for the device) the real state will be known after a few minures when the first poll happened.

     

    That's "interesting". I can imagine that the polling will eventually "set" the value. But I'm wondering how the variables get "restarted"? Also what about battery operated devices? The response to polling might come after many hours and hence some scenes might be "broken" for hours.

    Link to comment
    Share on other sites

    • 0
    9 minutes ago, cincura.net said:

     

    That's "interesting". I can imagine that the polling will eventually "set" the value. But I'm wondering how the variables get "restarted"? Also what about battery operated devices? The response to polling might come after many hours and hence some scenes might be "broken" for hours.

    See my edited post aboive: variables are not 'polled' and so will not automatically be 'set' to the value they had before the reboot. Second problem is that changing the value of a variable MANUALLY (by going to the variables-panel' and changing it there will not trigger anything. The variable needs to be changed by the gateway itself to be useful. AFAIK the only way to do this is to run an existing scene that will put it back to the desired state or write a small scene that does just that and run that scene. Not very user-friendly, I know but I'm not sure  there are other solutions like 'automatically resetting the variables to their pre-reboot' state. In some cases that would be just what you do NOT want, for example, when you suspect the state of a  variable (or a device) to be the exact problem for which you need the reboot.

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 1 hour ago, wienog said:

    variables are not 'polled' and so will not automatically be 'set' to the value they had before the reboot.

     

    I can't replicate this. I created a variable, changed the value in a scene and rebooted HC3. After reboot the variable had correct value.

    Link to comment
    Share on other sites

    • 0

    @cincura.net

     

    Yes, that is true but more of a coincidence than a fact. Where the Fibaro does get the values for it's devices and variables after a reboot is not clear to me. I suppose it does not make a list of which device is in which state and which varaiable has which value..

    I thought for some time that Fibaro after a reboot looked at the newest backup to decide the state of devices and variables , but i know now that is not the case either.

    I just don't know how they do it;

    But you are right: OFTEN but not always the varaibles , or some of them, have the value they had before the reboot.

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • Putting aside the variables, even for devices, after the reboot I see the previous states of the devices in UI/mobile app. Anyway.

     

    But as an extra test I modified the scene this way:

    Please login or register to see this image.

    /monthly_2020_09/image.png.f9b351f5d0a1359827f07e7088b192c4.png" />

     

    The two condition blocks evaluate (or at least should) always (OK, not in NULL logic) to `true`. Yet after reboot after pressing the button, the scene is not executed. What's more interesting is the fact, that setting the switch in condition to "Off" state in another scene does not solve the problem. I needs to be set to "On" (and "Off") and then in starts working as expected.

     

    How can this be reasonably explained?

    Link to comment
    Share on other sites

    • 0

    @cincura.net

     

    That's exactly what I said: the Home Center just DOES NOT KNOW after a reboot the state of things (be it devices or variables) untill you MANUALLY alter the state of a device, after which the new state is sent to the system and now it DOES know the state of that (and only that) device . For a variable as I said before you need to do it through a scene.

     

    As long ast the home center does not know the state of a device it will not ACT on a scene where that state is used as a condition, not even when you try to force it by maling a scene like the last one you showed.

    The reasoning of HC is this: "This guy asks me to do something if that device is ON or when that device is OFF but I have a problem because I just do not know what the state is, so I do nothing (not even when the scene is constructed in a way that it should run with the device-condition ON or OFF, the homecenter just refuses to process any scene that contains conditions for devices or variables of which he is not sure of the state or value, regardless)

     

    Probably what plays here is the information stored in the HC which shows the last time the state of a device was changed, something we use in scenes every day  ("If heating has been on for 20 minutes, turn it off").. Maybe, but that is just a guess, this information of last change is erased by a reboot and that is why the HC refuses to act.

    Edited by wienog
    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 9 hours ago, wienog said:

    That's exactly what I said: the Home Center just DOES NOT KNOW after a reboot the state of things (be it devices or variables) untill you MANUALLY alter the state of a device, after which the new state is sent to the system and now it DOES know the state of that (and only that) device . For a variable as I said before you need to do it through a scene.

     

    9 hours ago, wienog said:

    As long ast the home center does not know the state of a device it will not ACT on a scene where that state is used as a condition, not even when you try to force it by maling a scene like the last one you showed.

     

    Strictly speaking, when I set the state of the device to "Off" (and hence the HC3 (should) knows the state) via another scene, it still does not trigger. It needs to be "On" (and "Off" to be in proper state for the scene). Which is like ?‍♂️. Or maybe like ?‍♂️?‍♂️?‍♂️. I'm having trouble putting this behavior into my brain with my ~20 years of professional developer experience. Why would be it be done this way?

    • Thanks 1
    Link to comment
    Share on other sites

    • 0
    14 hours ago, cincura.net said:

     

     

    Strictly speaking, when I set the state of the device to "Off" (and hence the HC3 (should) knows the state) via another scene, it still does not trigger. It needs to be "On" (and "Off" to be in proper state for the scene). Which is like ?‍♂️. Or maybe like ?‍♂️?‍♂️?‍♂️. I'm having trouble putting this behavior into my brain with my ~20 years of professional developer experience. Why would be it be done this way?

     

    Why would it be done this way ?  Because it's Fibaro :-). Fibaro has it's reasons which reason does not understand...

    It's one of the strange details you find out about along the way and you learn to live with. Don't know if there is a structural solution for this behaviour. For example: making and saving a 'list' iof the state of devices and variables MIGHT be a solution, but, on the other hand: what if exactly the state of one of these devices is exactly the reson you need the reboot ? Then the whole problem starts all over again.

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 2 minutes ago, Hearts said:

    Work around is to force everything off after reboot ?

     

    In my case that would have to be on followed by off. I skipped on using the condition and rather do it in code in Lua.

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 1 minute ago, Hearts said:

    Ok, and you run this Lua manually after reboot or power failure ?

     

    No. Handling the condition in code seems to be working just fine (as if no reboot happened).

    Link to comment
    Share on other sites

    • 0

    Handling in block scenes working also fine. but if the reboot happened everything stopped working because of the (knows the state) 

    Link to comment
    Share on other sites

    • 0
    On 9/5/2020 at 8:11 PM, cincura.net said:

     

     

    Strictly speaking, when I set the state of the device to "Off" (and hence the HC3 (should) knows the state) via another scene, it still does not trigger. It needs to be "On" (and "Off" to be in proper state for the scene). Which is like ?‍♂️. Or maybe like ?‍♂️?‍♂️?‍♂️. I'm having trouble putting this behavior into my brain with my ~20 years of professional developer experience. Why would be it be done this way?

    That is correct: the change of state needs to be logged by HC3 If the state is "Off" and you make  a scene to put it to "off" nothing will happen. What you need to do is either toggle twice if you want the original state back.

    But i guess you found an other solution already through LUA.

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 2 hours ago, wienog said:

    That is correct: the change of state needs to be logged by HC3 If the state is "Off" and you make  a scene to put it to "off" nothing will happen.

     

    That's what's inconsistent and makes me wanna cry. After the reboot the condition is not evaluated to true or false because HC3 doesn't know the state, yet flipping the switch to off, when it thinks it's off, results in the behavior you/I described.

    Link to comment
    Share on other sites

    • 0

    This bug is extremely frustrating because it introduces random behaviour into the HC3 after a backup has been run. You cannot predict whether a scene will run because you don’t know whether it can evaluate the state of a device - even when that device’s correct state is show in the app and the web UI. 
     

    I find that if I manually change the state of the fibaro single switch and double switch and roller shutter devices, after the backup, then the HC3 knows them and scènes run normally.  So, after each backup I have to go around the house and change the state of almost every device.  The problem is, if you forget one device then any scene with that device as a condition MIGHT fail.

     

    Crazy. 
     

    Has anyone found a better workaround? @A.Socha Can you ask one of the developers for a suggested workaround please?

     

     

    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.

     Share

    ×
    ×
    • Create New...