All-in-One Scene: How to do it Better

[Rover 47]

16 minutes ago, cag014 said:

I think you do have a point... I will add to check devices status , the question how to use this data?

1. in displayed command to set note that the device is didabled?

2. to remove the device from the jM list during initialization (and to display the list of disabled devices) and entirely to ignore it during operation?

 

I think the second option is better solution.

Let me know if you have any other idea

3. Deliberately physically removing of a wall plug device has no influence on behaviour of AOQ. AOQ does not have to be initiated or anything done on the AOQ content. If the removed device is part of an alias group in order to turnOn or turnOff the group, simply deny the device. If the device is part of a jM condition, f.i. {"if {`WallPlug1`:value=false and `WallPlug2`:value=false}"} then WallPlug2:value will be denied if WallPlug2 has been physically removed.

Option 1 stays very usefull, but is no option but a nice feature, even is the device is not disabled, but dead (means removed).

 

The MAIN point is the WAF: my wife removes wall plugs but is not aware of the existance of AOQ.

Edited February 6, 2021 by Rover

[cag014 731]

2 hours ago, Rover said:

3. Deliberately physically removing of a wall plug device has no influence on behaviour of AOQ. AOQ does not have to be initiated or anything done on the AOQ content. If the removed device is part of an alias group in order to turnOn or turnOff the group, simply deny the device. If the device is part of a jM condition, f.i. {"if {`WallPlug1`:value=false and `WallPlug2`:value=false}"} then WallPlug2:value will be denied if WallPlug2 has been physically removed.

Option 1 stays very usefull, but is no option but a nice feature, even is the device is not disabled, but dead (means removed).

 

The MAIN point is the WAF: my wife removes wall plugs but is not aware of the existance of AOQ.

I think there is a solution right now in AOQ... set

wakeUpRate  = 0 --(minutes) wakeUp dead devices time rate. 0-disable

Now AOQ will not wakeUp this devices and no new notification will be sent till the devices will be connected again to the power.

[Rover 47]

1 hour ago, cag014 said:

I think there is a solution right now in AOQ... set

wakeUpRate  = 0 --(minutes) wakeUp dead devices time rate. 0-disable

Now AOQ will not wakeUp this devices and no new notification will be sent till the devices will be connected again to the power.

So as long you are not using this devices in conditional jM lines it works as desired?

[cag014 731]

8 hours ago, Rover said:

So as long you are not using this devices in conditional jM lines it works as desired?

It should work in conditions as well, with last reported value.

[Rover 47]

6 minutes ago, cag014 said:

It should work in conditions as well, with last reported value.

 If the device is part of a jM condition, f.i. {"`AllLights`","turnOff",{"if {`WallPlug1`:value=true and `WallPlug2`:value=true}"} and WallPlug2 has been physically removed in value "false", then this line will not work. So it is better to deny  the removed device in conditions than using the last used value.

 

I also saw that if a battery of a sensor is empty, or a sensor is not configured, and the sensor did not work because of that, it is not detected either in the initiation or in execution of a jM line.

 

[cag014 731]

Sensor are always in "deep" sleep mode. There is no way to controller to communicate with them. That's why there is a wakeUp time interval in which controller can send status commands.

In general there is no way to get any data from sensor. It's only updated when sensor sends the data.

Another problem that some devices could be dead for few minutes (especially devices installed far away from controller) and without trying to wake-up them (or  to send command) there is no way to know if the device is disconnected or dead for a period of time.

I have tried that scenario by disconnecting the device and remove it from AOQ, when the device has been connected again, AOQ could not determinate that the device is back on line.

By the way that's tthe reason why AOQ sends alerts on dead device...

 

[Rover 47]

1 hour ago, cag014 said:

Sensor are always in "deep" sleep mode. There is no way to controller to communicate with them. That's why there is a wakeUp time interval in which controller can send status commands.

In general there is no way to get any data from sensor. It's only updated when sensor sends the data.

Another problem that some devices could be dead for few minutes (especially devices installed far away from controller) and without trying to wake-up them (or  to send command) there is no way to know if the device is disconnected or dead for a period of time.

I have tried that scenario by disconnecting the device and remove it from AOQ, when the device has been connected again, AOQ could not determinate that the device is back on line.

By the way that's tthe reason why AOQ sends alerts on dead device...

 

OK, I understand about the battery sensor devices.

What about the removed wallplugs?

[cag014 731]

2 minutes ago, Rover said:

OK, I understand about the battery sensor devices.

What about the removed wallplugs?

As I mentioned, I can ignore them in AOQ, but there is no way to figure out when the device has been connected again.

By the way I don't think even HC3 has an answer for that. I mean in your code (Scenes or QA) you have same situation....

[Rover 47]

3 hours ago, cag014 said:

As I mentioned, I can ignore them in AOQ, but there is no way to figure out when the device has been connected again.

By the way I don't think even HC3 has an answer for that. I mean in your code (Scenes or QA) you have same situation....

I do not understand what you mean. I am talking about wallplugs, no battery devices. In LUA I can detect whether such a device is dead or not. So it should be possible to do the same in the LUA of AOQ. In API of wallplug I see category: dead = false. Polling for the moment when a dead device is live again is not necessairy, just "If device.value = true AND device.dead=false then...".

In this way a dead (physically removed) non battery device would be neglected in jM conditions, not?

[cag014 731]

AOR moves one step forward...

1. Thanks to @jgab @10der and @petergebruers now AOR runs under

Please login or register to see this link.

. Very powerful editor and several instances of AOR could run in parallel.

Please let me know if you interesting in that and I'll post configuration files.

Please login or register to see this spoiler.

2. Have added an option to execute user functions. The command format is

trueAct={"<funcName>","runFunc,<arg1>,...,<arg5>"}

in the function all HC3 standard fibaro commands are supported. Since fibaro commands can not support slave's devices few special AOR commands have been added.

AOR.call("500'hc2","turnOn")

AOR.call(300,"turnOff)

AOR.getValue("394'hc2","power")

AOR.setGlobalValue(<GV>,"value") -- AOR local variables supported also.

 

The function are written in user_func.lua file. please download an example and save it in your project directory

 

Please login or register to see this attachment.

Please login or register to see this attachment.

Edited February 8, 2021 by cag014

[cag014 731]

1 hour ago, Rover said:

I do not understand what you mean. I am talking about wallplugs, no battery devices. In LUA I can detect whether such a device is dead or not. So it should be possible to do the same in the LUA of AOQ. In API of wallplug I see category: dead = false. Polling for the moment when a dead device is live again is not necessairy, just "If device.value = true AND device.dead=false then...".

In this way a dead (physically removed) non battery device would be neglected in jM conditions, not?

Yes, as I said AOQ can determinate if the device is dead, but when device connected is not always detected unless command or polling executed.

In addition always to monitor the status of all devices will take time (especially if you have few slaves)  and will slowdown AOQ performances.

let me see what could be done...

[cag014 731]

@Rover

Since you do know which devices

1 hour ago, Rover said:

I do not understand what you mean. I am talking about wallplugs, no battery devices. In LUA I can detect whether such a device is dead or not. So it should be possible to do the same in the LUA of AOQ. In API of wallplug I see category: dead = false. Polling for the moment when a dead device is live again is not necessairy, just "If device.value = true AND device.dead=false then...".

In this way a dead (physically removed) non battery device would be neglected in jM conditions, not?

By the way you can set this condition  right now. AOQ supports  any valid property, so in your case it will be

{"`AllLights`","turnOff",{"if {`WallPlug1`:value=true and `WallPlug2`:value=true} or {`WallPlug1`:value=true and `WallPlug2`:dead=true}"}

Let me know if it works

Edited February 7, 2021 by cag014

[Rover 47]

6 hours ago, cag014 said:

@Rover

Since you do know which devices

By the way you can set this condition  right now. AOQ supports  any valid property, so in your case it will be

{"`AllLights`","turnOff",{"if {`WallPlug1`:value=true and `WallPlug2`:value=true} or {`WallPlug1`:value=true and `WallPlug2`:dead=true}"}

Let me know if it works

I will try that. Still better if it would be embedded in AOQ. Since I am migrated HC2 to HC3, the performance of slaves are not interesting for me, but maybe for others. In that case an AOQ switch could avoid the the testing of the condition of devices.

[Rover 47]

On 2/6/2021 at 10:04 PM, cag014 said:

I think there is a solution right now in AOQ... set

wakeUpRate  = 0 --(minutes) wakeUp dead devices time rate. 0-disable

Now AOQ will not wakeUp this devices and no new notification will be sent till the devices will be connected again to the power.

WakeUpRate=0 still initiates e-mail All-in-One-1 Alert (Dead) and All-in-One-2 Alert (Dead).

[cag014 731]

7 minutes ago, Rover said:

WakeUpRate=0 still initiates e-mail All-in-One-1 Alert (Dead) and All-in-One-2 Alert (Dead).

Yes, the dead notifications is always sent, but now AOQ will not try to wakeUp the device and shouldn't send more notifications about wake/dead statuses.

To stop all dead notifications you can set

deadNote    = false

But in this case you could miss when important devices are dead from some unexpected reason

 

[Rover 47]

2 minutes ago, cag014 said:

Yes, the dead notifications is always sent, but now AOQ will not try to wakeUp the device and shouldn't send more notifications about wake/dead statuses.

To stop all dead notifications you can set

deadNote    = false

But in this case you could miss when important devices are dead from some unexpected reason

 

That is indeed not what I want.

[cag014 731]

I think the best solution is to create "dead" table with default value defined by user. For example

jDead={

 ["320"]={value=90, power=100, state=true),

["400"]={value=true),

}

Now if the device dead, this values will be used by AOQ for states, conditions and calculations

 

What do you think about it?

Edited February 8, 2021 by cag014

[Rover 47]

11 minutes ago, cag014 said:

I think the best solution is to create "dead" table with default value defined by user. For example

jDead={

 ["320"]={value=90, power=100, state=true),

["400"]={value=true),

}

Now if the device dead, this values will be used by AOQ for states and conditions

 

What do you think about it?

I do not think I would use this feature, better to neglect dead (= physically removed) devices, like in the previous (`WallPlug2`:dead=true) construction.

In that case I do not like to have each day dead notifications until Christmas time has arrived again.

Be aware of the fact that I only mention removable devices, in my case only wallplugs.

Edited February 8, 2021 by Rover

[cag014 731]

2 minutes ago, Rover said:

I do not think I would use this feature, better to neglect dead (= physically removed) devices, like in the previous (`WallPlug2`:dead=true) construction.

In that case I do not like to have each day dead notifications until Christmas time has arrived again.

Once the device included in table, AOQ will use defined value w/o sending notifications... it means user knows that the device intentionally could be removed(dead). 

When device will be back on line, AOQ will start to use real reported values.

In addition when device is dead no commands (turnOn/Off and etc) will be sent....

Currently AOQ sends the commands to dead devices and that takes time and overload on Zwave traffic (when devices dead, controller tries to send the command three times!)

[Rover 47]

14 minutes ago, cag014 said:

Once the device included in table, AOQ will use defined value w/o sending notifications... it means user knows that the device intentionally could be removed(dead). 

When device will be back on line, AOQ will start to use real reported values.

In addition when device is dead no commands (turnOn/Off and etc) will be sent....

Currently AOQ sends the commands to dead devices and that takes time and overload on Zwave traffic (when devices dead, controller tries to send the command three times!)

Not sending notifications if dead is desired. Also not sending commands to dead device is preferred. But why not neglect condition of dead device instead of pretending a defined value ? F.i. in an alias group condition to turnOff the group the pretended value should be true and in an alias group condition to turnOn the group the pretended value should be false, very unneeded complexity.

Edited February 8, 2021 by Rover