Trigger when bulb goes online


#1

1) Give a description of the problem
I want to turn on/off a bulb based on the status of another bulb. The first bulb will either be (online AND on) or (offline). The second bulb (to be controlled will always be online.

2) What is the expected behaviour?
See above and code below.

3) What is happening/not happening?
This code works. However I would expect there to be a way of knowing when the bulb connects to the network instantly.
Does anyone know if there is any trigger or message sent by a device upon reconnecting to the mesh?
I fully understand that when taking the bulb offline I must expect some latency. Is there anything I can do to poll the health status from the bulb in question more frequently?
Or is there anyway other way I can reduce the time between the healthStatus checks?

4) Post a Green Snapshot of the piston!

5) Attach logs after turning logging level to Full


#2

Check the IDE for correct values, it’s case sensitive


#3

Thanks for the quick answer. I assume you sent it before I even got the post in order. All the code works so I don’t understand what you are referring to when you say that the values are case sensitive. Is it more correct to use “OFFLINE” and “ONLINE”?


#4

I am not sure if it’s the handler that assigns the value but most often than not, the value in the IDE that shows is in upper case. WebCoRE’s text operators are case sensitive

Edit: Regarding healthStatus, I don’t believe that can be used as an actual trigger for a piston. You might have to use a timer to poll for healthStatus instead.

Something in the likes of this…
image


#5

It requires a bit of preparation, but one thing that ALWAYS happens in my house after the power returns is certain lights will come back on to 100% brightness.

Knowing this, I am careful to never program the bulb in question to ever go higher than level 99%. This way, I have webCoRE monitor one bulb, and whenever it goes to 100% brightness, it knows that the power is back on. At that point, the piston can do whatever we like…

It works like a champ, as long as you never allow webCoRE (or your household) to turn that bulb to 100%. (99% becomes your new max brightness)


Pro Tip:

Typically, a bulb jumps to full brightness the moment power is restored… but it usually takes somewhere between 10-30 seconds for the bulb to connect to the hub. Once that happens, then automation can instantly take over.


#6

Thanks WCmore. Sadly this does not happen for my bulb. However the following always happens:

  • Configure command is sent to the bulb.
  • The check interval is changed.

I believe there should be a way that I can use the configure comand that is being sent as a trigger.

Does anyone know how I can do that? Alternatively why it will not work?


#7

When making an IF CONDITION, any of the drop down should work…

pic

When making an IF TRIGGER, the highlighted ones should not work…


They work similarly to $twcweather… The data is there and available, but not pushed out to other devices. (they have to be queried)


#8

Hi. I found a solution that will work for now that is a variation on WCmore’s suggestion of using the light level.
By making a custom device handler (99.9% a copy of the edvaldeysteinsson/ IKEA-Tradfri I could change what happens when the bulb configured. At the end of the “def configure()” block I added setLevel(99).

I can now use this change to trigger for a webCoRE script (which of course can do virtually anything).

I am still not satisfied. It seems strange that I cannot simply use the configure command as a trigger.

I also modified the checkInterval to 60 for a quicker response when turning the light off.
I could then use a timer to check the health status every minute as well.
I understand that lowering the checkInterval is bad for battery life, but as I currently do not have any battery devices on the given hub I don’t think it should be a problem. I assume someone will tell me why this is a bad idea and I don’t have a problem with using a larger value, it just does not seem as nice.


#9

The command events don’t seem to be exposed to users for subscriptions, or if they are it isn’t documented.

There seems to be various attributes such as ‘checkInterval’, ‘DeviceWatch-DeviceStatus’, ‘DeviceWatch-Enroll’ and ‘healthStatus’ that are associated with Device Health and you may be able to trigger on those. However if, when, and how they are used seems to vary a lot so there probably isn’t a general solution in there anywhere.