Fibaro Switches DTH differentiating between Physical & Programmatic interactions

[nigelmwilliams7]

1) Give a description of the problem
So it seems the Device Handler I am using for my Fibaro Single/Double switches arent differentiating between Physical & Programmatic interactions. I am using those written by erocm1231, https://community.smartthings.com/t/release-fibaro-single-switch-2-fgs-213-double-switch-2-fgs-223/82272

2) What is the expected behavior?
Differentiate in conditions whether its physical or programmatic interaction

3) What is happening/not happening?
switch01’s switch physically changes picks up both physical and programmatic interactions

4) Post a Green Snapshot of the piston
(UPLOAD YOUR IMAGE HERE)

5) Attach any logs (From ST IDE and by turning logging level to Full)
(PASTE YOUR LOGS HERE BETWEEN THE MARKS)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

[Robin]

I’ve tried and tried to solve this… I know how it should work in the device handler but it simply won’t behave no mater what I tweak!!

My only reccomendation is to use the scene ID’s as these are only sent on a physical press.

You’ll need to upgrade the handler to the latest one from codesaur:

[RELEASE] Fibaro Dimmer 2 (FGD-212) - Advanced DTH (V2)

Then set parameter 28 to 1 to enable scenes.

Write a piston as follows

IF Dimmer name’s scene changes to 16
AND
Dimmer name’s switch IS on
THEN
dimmer was turned on physically
ELSE
Dimmer was turned on programmatically

[nigelmwilliams7]

Robin

Your a star for the advice

So I use switches and not dimmers
I have set the setting in the parent device handler to send a sceneID from erocm1231’s device handler

Here are the parameters for the parent switch that has 2 children

What do you suggest for this?

[nigelmwilliams7]

And all I can see for the parent switch is

and the child switch is

I am happy to work with you and Eric to get this working if you like?

[Robin]

I’ve never owned the switches so I’m not sure… for the Dimmer there is a custom attribute called ‘scene’, but it doesn’t appear you have that for the switch.

You might need need to work with @erocm1231 to get the attribute exposed to webCoRE, and maybe he can solve the physical / programmatic issue as well.

Good luck!

[nigelmwilliams7]

Thank you
In the short term I will use a Global boolean variable to determine if it is physical or programmatic interaction
I can set the boolean to true in webCoRE before every programmatic interaction.

if switch-01 changes then
if switch-01 is ON then
If switch-boolean is TRUE then
programmatic action
switch-boolean = false;
else
physical action
endif
endif
endif

[DanielSiegel]

Robin

I realize this was an old post, but I dont know whether things have changed in this regard.
I have now completed my installation of 100+ Fibaro Dimmer 2 and Single Switch 2 devices, and am turning my attention to “scenes” (broadly interpreted).

With your help, I experimented with webCore a few months ago, and am now finding that the ability to distinguish between “physical” and “programmatic” changes would be a very useful feature. While I see that feature in webCore, I understand that Fibaro and other devices dont seem to provide state change notifications that make this distinction (assuming that is still true).

I have also discovered that it would be nice to trigger a scene when a switch is pressed physically but doesnt change its state (ie, it is physically pressed On when the Fibaro is already on, or physically pressed Off when the Fibaro is already Off).

Let me try to describe one of my scenarios to better describe these issues.

I have a “great room” with 2 switch locations – one at each of the great room’s two primary entry/exit points. One is connected to a “central” circuit of lights, while the other is connected to a “far wall” circuit of lights. And the room contains multiple other switches and circuits.

My goal is to set up two different “entry” scenes depending on which of these two primary switches is physically pressed On (each of which turns on particular circuits, including the one physically connected to the relevant switch), and a single “exit” scene that turns off ALL of the lighting circuits in the great room.

One problem I encountered is the “physical” v “programmatic” issue, which causes the scene to be triggered whenever I programmatically (classic App, Alexa, etc) turn on the “central” or “far wall” circuits. Even with the “scene ID” workaround you described above, the scene ID does not change if the Fibaro previously was, for example, turned on physically, but turned off programmatically.

I also found that the lack of a state change (eg, physically turning Off a Fibaro that is already Off) prevents a “room off” scene from being triggered if the particular Fibaro (eg, “far wall” circuit) is already Off because someone entered the room by pressing the other Fibaro (“central”) which didnt turn on the “far wall” circuit as part of that particular entry scene.

Anyway, I appreciate any thoughts you have on either of these 2 notification issues (physical v programmatic notifications), and the lack of a notification when a device is physically pressed but does not change state).

Sorry for the long explanation.
Thanks
Dan

[Robin]

Nothing has changed, physical v programmatic will never work in a mesh network… as soon as the signal is one hop away in the network, the data is lost.

It’s included in webCoRE because it’s in the ST documentation, but it has never worked properly.

[DanielSiegel]

That’s too bad.

Based on some limited testing, it does appear that Fibaro sends out the Scene IDs (per your prior post, with the chart from the Fibaro manuals) only in response to a physical press of the switch (and regardless of whether the light switch actually changed state). For example, my Dimmer 2 switches are set to “roller blind” mode (10 for ON and 11 for OFF). If I physically press ON, the Scene ID will stay or change to 10, regardless of whether the light was On or Off.

For example, if I physically press a switch On, the Scene ID changes from 11 to 10. But if I programmatically turn it Off, the scene ID remains at 10, and will “stay” at 10 if I then physically turn it back On.

Moreover, if I physically press On (or Off) when the light is already in that state, no Routine will ever be triggered.

So, while the Scene ID is a good indicator of the state of the last physical press, I’m still not sure I can use it to consistently distinguish physical from programmatic actions.

In short, there appear to be 2 “problems.”
1. The Fibaro only triggers a routine if its lighting state CHANGES (On to Off or Off to On).
So, even if the Scene ID reflects a physical press, no Routine will be triggered.

 2.  The Fibaro Scene ID only represents the "most recent" physical press of S1 or S2
            So, a physical press may "stay" in that state or "change" to that state
            While webCore can test for either, such a test will not consistently identify a physical press.

Is my analysis correct?
In other words, even using the Scene ID “workaround,” these 2 problems still appear to prevent the consistent triggering of webCore pistons solely from a physical press.

Do you know of any way to trigger a webCore piston when a Scene ID is sent (even though the lighting state of the device did not change)?

[Robin]

You are obviously using toggle switches, perhaps use momentary switches instead (it’s what the dimmer 2 is truly intended for).

Alternatively, change parameter 22 to 0 (so each change of the switch changes the state of the load, rather than keeping the switch in sync with the load), this is actually the default setting but the behaviour you describe makes me think you have changed that default?

[DanielSiegel]

Not sure I understand, though I suspect my options are limited.

I have a physical piece of glass with top/bottom touch sensors behind the glass, along with a custom PC board interface that generates 3 signals (On, Off and Common) whenever a touch sensor is pressed or held. These 3 signals connect to the Fibaro switches on 3 wires.

To successfully control the Fibaro Dimmer 2, I need to set it to “roller blind” mode and connect the On, Off and Common wires (to the S1, S2 and Sx Fibaro inputs. This enables me to turn the Fibaro Dimmer 2 both On and Off, as well as manually dim up or down by touching and holding down my press of the relevant touch sensor thru the glass.

To successfully control the Fibaro Switch 2, I need to set it to "momentary’ mode. The physical connections are a bit more complicated, as I need to insert an additional relay into the mix. But it turns On or Off the “moment” I press the on or off touch sensor thru the glass.

What I dont understand is what you mean by keeping the switch in sync with the load. When I press On, the Scene ID either “changes” (to 10) or “stays” (at 10). But the load only changes if it was Off (regardless of how it got that way – physically or programmatically).

Apart from “toggle” behavior, how could the switch stay in sync with the load?
Also, I have never seen parameter 22 on the Fibaro Dimmer 2. Would this work in roller blind mode?

[DanielSiegel]

I think I just solved all of these problems.
Or, more accurately, I should say that YOU solved all of these problems.

I found a few old posts of yours relating to Fibaro and Scene IDs.
After a little testing, I realized that I can implement any given scene via a webCore piston.
And I can trigger that piston both Physically and Programmatically.

To physically trigger the webCore piston, I can use the On Event command and a Switch/Case statement based on the value of a particular Fibaro’s Scene ID. What I discovered was that Fibaro sends this Scene ID when a switch is physically pressed – regardless of whether the load state changed and regardless of whether the Scene ID changed or stayed the same.

If I also want to trigger the same webCore piston programmatically, I create a “blank” Routine (which is never automatically triggered) and use an IF statement in the piston based on the name of blank Routine. Then, I can remotely trigger that Routine by pressing it manually in the SmartThings App, or via voice control (Alexa, etc) or other connected apps.

Most importantly, if I remotely change the state of the individual Fibaro switch (eg, from the SmartThings App screen listing my Things), the scene will not be inadvertently triggered.

This accomplishes all of my scene-related goals, and effectively enables me to distinguish Physical from Programmatic invocations of my Fibaro switches. Also looks like the Fibaro Single Switch 2 has similar functionality.

Thanks again.
Dan

[Robin]

Parameter 22 is not relevant, I missed that you had the touch button setup and thought you were using regular toggle switches (not blind switch mode).

I seem to remember issues with the scenes not triggering ‘on event’ when the scene hasn’t changed from the last physical action, but it’s been a while and i can’t test right now… if it’s working for you that’s great.

[DanielSiegel]

Robin

This does seem to be working for me, though I have experienced a few anomalies (just testing 2-3 scenes for a few days now) that make me wonder if my approach is sound.

My general approach (modeled after much of your sample code) is to have a “conductor” piston that is invoked (by physical switch presses or programmatic/remote scene invocations from an App, Alexa, etc), which calls other pistons to implement the scenes for those particular events. I also created generic “switch ON” and “switch OFF” pistons since most of my scenes will simply turn On or Off a set of lighting circuits in response to physically pressing a particular switch or programmatically invoking a desired scene. For some scenes, I will need to create other scene-specific pistons that dont fit into this general On/Off structure (eg, turning on a Fan for 10 minutes, dimming certain lights to 20%, 50%, etc).

More importantly, I am wondering whether my “2-conductor” structure has flaws (where one conductor handles physical presses On/Off, and the other conductor handles programmatic/remote scene invocations). The only structure I am aware of for the physical presses was the “On Event” structure for receiving Scene IDs from my Fibaro switches (which seems to be reliable - at least so far). However, I did not see any way to respond to “Routines” using this structure.

So, I created a similar “Routine conductor” that responds to “blank” Routines (and invokes other pistons to implement desired scenes associated with those blank Routines). My blank Routines are never invoked automatically by physically pressing a switch, and never do anything even in response to being selected in an App, via Alexa, etc. Their sole purpose is to be associated (by their name) with a particular desired scene and detected by the “Routine Conductor” piston, which will invoke another piston to implement the associated scene.

But the only structure I am aware of to detect invocation of a Routine is the “If-Then-Else” structure.
So, I use that structure in my separate Routine Conductor piston.

I guess I could have combined both structures into a single piston to avoid having 2 pistons constantly running and waiting to be invoked by “On Event” or “If” statements. The problem is that I dont fully understand how these conductors are executed. For example, are they running constantly, or simply waiting to be invoked by an event (Scene ID being sent, Routine being invoked, etc)? The “On Event” structure sounds more similar to what I am familiar with in an event-driven environment, whereas the “If” structure makes me wonder how frequently these “If” and “Else If” statements are being executed.

Appreciate any thoughts you have since you are far more familiar with this programming/execution environment than I am.

Thanks
Dan

[Robin]

No piston can run constantly, ST has time limits on individual executions.

Pistons subscribe to events, ST pushes those events to the pistons when they occur.

I’m not a big fan of ‘else if’ statements, they work fine but can be harder to tweak / understand.

For routines I just string a series of stand-alone IF THEN statements:

For fibaro scenes I like to use a switch case (This blank example is for the scene ID’s generated when using momentary switches, for the up, middle, down switches you use, it will need tweaking):

But the great thing about WC is that no way is ‘right’… if it works for you, and you understand the logic, don’t change a thing.

[DanielSiegel]

I see. I can certainly avoid the “else if” statements, and just string “if then” statements as you suggest.

But it sounds like you are saying that my use of 2 conductor pistons (one for Fibaro scenes using a sequence of “On event” statements, and another for Routines using “if then” statements) is no better or worse than trying to consolidate all of this into a single conductor piston.

I was just confused by the fact that an IF statement inside a piston could be event driven, and that the piston itself would only be invoked when an IF statement’s condition was met.

If I understand what you are saying, both pistons are “event driven” and only invoked when the events occur – ie, when a Fibaro sends a Scene ID or a Routine is executed.

If that’s the case, I may just be experiencing some occasional strange Zwave behavior.
For example, I have certain lights that are only part of my “All Off” scene, yet once or twice those switches turned “On” with all the others. Could be a bug in my attached code, but I havent found it yet. And, so far, everything is usually working fine.

Thanks again for your help and suggestions.

[Robin]

Where you statement only contains a condition, or multiple conditions, those conditions behave like triggers.

Where you have a mixture of triggers and conditions, only the triggers are subscribed to events, the conditions are evaluated after one of the triggers gets pushed.

‘IF’ and ‘On Event’ are almost the same thing, except:

• Anything within the brackets of ‘On Event’ is essentially a stand alone piston, it’s the only part of a larger piston that fires when that event occurs and nothing else is evaluated,
• When an ‘IF’ fires, conditions in other parts of the same piston get evaluated as well, if true they also fire.

Example 1:

[
On event from front door
IF door is open then (This is a condition inside an ‘on Event’)
Send Message - Door state changed
end if
end on event
]
[
IF X switch is on then (This is a condition)
Send Message - Switch is on
end If
]

• Door opens when switch is on - door message sent
• Door opens when switch is off - door message sent
• Door closes when switch is on - no message sent
• Door closes when switch is off - no message sent
• Switch turned on when door is open - switch message is sent
• Switch turned on when door is closed - switch message is sent
• Switch turned off when door is open - no message sent
• Switch turned off when door is closed - no message sent

Example 2:

[
IF door is open (This is a condition)
Send Message - Door is open
end on event
]
[
IF X switch is on then (This is also a condition)
Send Message - Switch is on
end If
]

• Door opens when switch is on - both messages sent
• Door opens when switch is off - door message is sent
• Door closes when switch is on - switch message is sent
• Door closes when switch is off - no message sent
• Switch turned on when door is open - both messages sent
• Switch turned on when door is closed - switch message is sent
• Switch turned off when door is open - door message sent
• Switch turned off when door is closed - no message sent

[Robin]

12 posts were split to a new topic: Forum HTML Tags and Formatting

[Robin]

Sorry OP… we went a bit off topic there, so I have split the HTML discussion over to here:

Forum HTML Tags and Formatting

Nice breakdown @RobinWinbourne!! I think your post would be great information to add to the Wiki… By the way, how did you highlight the text here in the forums??