(SOLVED) Uninitialized var

[rlkoshak (Rich Koshak)]

@Teknix1

When the system is started, have everything turned off, this is the default state.

Put all the lights into a Group. I’ll call it Lights. Then

rule "Set lights to OFF"
when
    System started
then
    createTimer(now.plusSeconds(30), [ | Lights.sendCommand(OFF) ])
end

The Timer should help to avoid that parallel loading problem.

But the question is why must they be OFF? Why not leave them as they are and only turn some ON or OFF if an automation event was missed (e.g. the time of day changed)? If you use retained messages for the commands, then when OH comes up it will immediately know what state the lights are supposed to be in if they are online. If they are offline then the lights will become that state when they come back online.

@Teknix1

If devices connect (MQTT) before or after the system started/initialization they need to return to the state saved in that variable. Currently something is querying the device when it connects (LWT) which triggers a change and messes up everything, I can’t tell the difference between that an a physical press of the button. Still working on this part…

Like I described, just use a retained message when you command the light and the light will return to that state when it comes back online (e.g. in a power outage).

There is no such thing as “querying” in MQTT. There are either unretained messages in which case the client needs to be connected to receive the message, or retained messages in which case the client will receive the last published message even if it wasn’t connected when the message was sent.

@Teknix1

When devices reconnect for whatever reason; network down, router restart, device update, etc. They need to return to a predetermined state (my var), not to what they were last at. Very similar to item #2 but this could be at any time, not just on system start.

So you want them to return to the last state they were commanded to from OH. That is exactly what a retained message would do.

@Teknix1

Be able to control devices through Google Home even when devices aren’t all connected. The devices should “auto-heal” when they reconnect back to OH.

Again, retained messages would solve this.

@Teknix1

I eventually want to write a few light strobe/flashing sequences so I’ll need to keep vars of other internal states so it’ll become a lot more complicated than this.

See Loop of flashing light inside a timer - #2 by rlkoshak

@Teknix1

This list may seem unreasonable to some, but I don’t think so

It’s not unreasonable, you are just going about achieving it the hard way.

@Teknix1

All of these should be simple but the OH framework seems to really get in the way here.

This really isn’t OH’s job. Use the capabilities of MQTT to your advantage.

But even if it were OH’s job, you are still going about it the hard way. Another simple approach would be:

• put all the lights into one Group, we’ll call it Lights
• configure Lights* to be persisted on everyChange and restoreOnStartup
• run a simple Rule at startup to sendCommand to the lights with the restored state from the database

rule "Restore lights"
when
    System started
then
    createTimer[now.plusSeconds(30) | Lights.members.forEach[ light | light.sendCommand(light.state) ]
end

To restore a light to it’s previously commanded state when it comes online (assuming you don’t use retained messages) you would need to get some sort of message to indicate that it has come online. You could look for the LWT message and then use the first message after that to indicate it has come back online to then sendCommand the Item’s current state in OH. Again, using Persistence the rule would look something like (using Design Pattern: Associated Items):

import org.eclipse.smarthome.model.script.ScriptServiceUtil

rule "Came back online?"
when
    Item Member of Lights changed
then
    val lwt = ScriptService.getItemRegistry.getItem(triggeringItem.name+"_LWT")
    hist = triggeringItem.previousState(true).getTimeStamp()
    if(lwt.lastUpdate.isAfter(hist)) triggeringItem.sendCommand(hist.state)
end

If the previous state of the Light that is different from the current state is before the most recent LWT message, this is the first message after the LWT so send the last state of the light back to the light.

NOTE: I just typed in these Rules, they likely contain errors.

@Teknix1

have events for when devices connect.

That is something your device needs to implement and publish a message. There isn’t anything you can do from OH. MQTT doesn’t work that way.

@Teknix1

PreviousState isn’t available unless I turn on persistence (correct me if I’m wrong),

If you have a Rule triggered with a changed trigger, then there will be a variable called previousState. This variable does not require Persistence.

@Teknix1

I don’t quite get the reason for the system started event if it doesn’t guarantee that everything is started or that it runs after the global variables have been initialized.

It’s a long time bug that hasn’t been fixed.

@Teknix1

I might as well throw an “if state === null then return” at the top of all my rules. Actually would that be bad?

It wouldn’t be bad but I think this entire approach to do what you are after is not the best way to achieve what you are after so I’m questioning whether it’s worth dealing with this particular problem in the first place.