Hello, I know this horse has been flogged often and I’ve looked through what I can find but nothing seems to handle it reliably for me. I come from VeraLand and used PLEG extensively (that communities webCoRE equivalent), now trying to wrap my head around pistons and webCoRE.
What I’m trying to do is create a simple dimmer-switch control of a dimming device. I’m using a simple one-one situation to train up on piston use and have a couple questions. I’ve setup a piston to sync a dimmer device to the state of a dimmer switch. It works, sorta. It takes a second or two and is erratic in how it gets to the end-game. i.e. there are a few light level convolutions along the way, sometimes from the starting point, say 25% up to 100% before dropping to zero or a few quick stops at various random #'s along the way in the case of turning the switch off. etc. I suspect one reason is the ramp up/down built into the switch. I expect I can fix some of it by adjusting the ramp in the switch parameters. Which I’ll try when I figure out how to do that.
I started with this:
if
Kitchen Dm Sw’s level changes
then
with
Truss_LED
do
Set level to Kitchen Dm Sw’s level%
end with;
end if
Worked well and very quickly but did have a flicker or two (likely due to the ramp up/down). On the downside, I could change the level on the switch and the lights would go up/down accordingly even if the switch state was ‘off’’.
So I added the on/off logic and now I’m at this:
It’s a little slower to execute, but seems to do OK with both on/off and dimming changes except for the flickering up/down along the way. The log shows the level changes to target or ignored as it wouldn’t change anything… it’s words, not mine.
Wonder if someone can suggest better/more efficient code/logic. I’m using a trigger before the state check so it should be fairly efficient. Since the switch (a homeseer WD100+) holds both level and switch I can’t just check for 0 level and set off as I did with Vera’s “target level” to infer off vs on (anything above zero.)
Is there a better way to handle the “dynamic” live dimming than using level change trigger?
Lastly I have a very automated (i.e. lots of code) setup in vera that I’m planning to migrate over using pistons, several will interact with this piston via the device and switch, is it easier on the system if I just use the switch to control the device from those other pistons or is it preferred to “call” interaction piston-a-piston i.e. ‘inter-piston’ variables. My goal is to keep things as snappy as possible and as fool proof as I can make them, while keeping the switch and device in sync, which I expect to do by making the switch the master… I’ve tried direct association between the two but for whatever reason my forehead gets bloody and the devices are still not speaking.
Thanks for any suggestions/insights. I’ll drop the full log below. In this log I start with both off, then turn up the dimmer level of the switch, then turn on the dimmer, followed by another dimmer level change followed by off:
9/21/2017, 8:16:52 AM +685ms
+2ms ╔Received event [Kitchen Dm Sw].switch = off with a delay of 74ms
+130ms ║RunTime Analysis CS > 18ms > PS > 50ms > PE > 61ms > CE
+140ms ║Runtime (36511 bytes) successfully initialized in 50ms (v0.2.0e7.20170906) (137ms)
+141ms ║╔Execution stage started
+160ms ║║Cancelling condition #8’s schedules…
+162ms ║║Condition #8 evaluated false (9ms)
+163ms ║║Cancelling condition #1’s schedules…
+164ms ║║Condition group #1 evaluated false (state changed) (13ms)
+177ms ║║Comparison (enum) off changes_to (string) off = true (1ms)
+179ms ║║Cancelling condition #14’s schedules…
+181ms ║║Condition #14 evaluated true (10ms)
+182ms ║║Cancelling condition #11’s schedules…
+183ms ║║Condition group #11 evaluated true (state changed) (14ms)
+187ms ║║Cancelling statement #12’s schedules…
+218ms ║║Executed physical command [null].off() (22ms)
+219ms ║║Executed virtual command [Truss_LED].setSwitch (25ms)
+224ms ║╚Execution stage complete. (83ms)
+232ms ╚Event processed successfully (232ms)
9/21/2017, 8:16:46 AM +760ms
+1ms ╔Received event [Kitchen Dm Sw].level = 80 with a delay of 167ms
+257ms ║RunTime Analysis CS > 97ms > PS > 92ms > PE > 68ms > CE
+266ms ║Runtime (36510 bytes) successfully initialized in 92ms (v0.2.0e7.20170906) (263ms)
+267ms ║╔Execution stage started
+287ms ║║Comparison (integer) 80 changes = true (1ms)
+289ms ║║Condition #8 evaluated true (9ms)
+302ms ║║Comparison (enum) on is (string) on = true (2ms)
+304ms ║║Condition #10 evaluated true (14ms)
+305ms ║║Condition group #1 evaluated true (state did not change) (26ms)
+310ms ║║Cancelling statement #6’s schedules…
+341ms ║║Executed physical command [null].on() (20ms)
+342ms ║║Executed virtual command [Truss_LED].setSwitch (22ms)
+392ms ║║Executed physical command [null].setLevel([80]) (43ms)
+393ms ║║Executed [Truss_LED].setLevel (45ms)
+409ms ║║Condition #14 evaluated false (8ms)
+410ms ║║Condition group #11 evaluated false (state did not change) (11ms)
+414ms ║╚Execution stage complete. (147ms)
+423ms ╚Event processed successfully (423ms)
9/21/2017, 8:16:39 AM +541ms
+2ms ╔Received event [Kitchen Dm Sw].level = 44 with a delay of 89ms
+118ms ║RunTime Analysis CS > 17ms > PS > 50ms > PE > 50ms > CE
+127ms ║Runtime (36508 bytes) successfully initialized in 50ms (v0.2.0e7.20170906) (124ms)
+129ms ║╔Execution stage started
+145ms ║║Comparison (integer) 44 changes = true (1ms)
+147ms ║║Cancelling condition #8’s schedules…
+148ms ║║Condition #8 evaluated true (8ms)
+161ms ║║Comparison (enum) on is (string) on = true (2ms)
+163ms ║║Condition #10 evaluated true (13ms)
+164ms ║║Cancelling condition #1’s schedules…
+165ms ║║Condition group #1 evaluated true (state changed) (26ms)
+169ms ║║Cancelling statement #6’s schedules…
+200ms ║║Executed physical command [null].on() (22ms)
+201ms ║║Executed virtual command [Truss_LED].setSwitch (24ms)
+463ms ║║Executed physical command [null].setLevel([44]) (255ms)
+464ms ║║Executed [Truss_LED].setLevel (257ms)
+479ms ║║Condition #14 evaluated false (8ms)
+480ms ║║Condition group #11 evaluated false (state did not change) (11ms)
+484ms ║╚Execution stage complete. (355ms)
+491ms ╚Event processed successfully (490ms)
9/21/2017, 8:16:33 AM +688ms
+1ms ╔Received event [Kitchen Dm Sw].level = 6 with a delay of 67ms
+388ms ║RunTime Analysis CS > 24ms > PS > 305ms > PE > 59ms > CE
+398ms ║Piston waited at a semaphore for 258ms
+400ms ║Runtime (36575 bytes) successfully initialized in 305ms (v0.2.0e7.20170906) (398ms)
+401ms ║╔Execution stage started
+417ms ║║Comparison (integer) 6 changes = false (1ms)
+418ms ║║Condition #8 evaluated false (7ms)
+420ms ║║Condition group #1 evaluated false (state did not change) (8ms)
+435ms ║║Condition #14 evaluated false (11ms)
+436ms ║║Condition group #11 evaluated false (state did not change) (12ms)
+440ms ║╚Execution stage complete. (38ms)
+465ms ╚Event processed successfully (465ms)
9/21/2017, 8:16:33 AM +681ms
+1ms ╔Received event [Kitchen Dm Sw].switch = on with a delay of 60ms
+108ms ║RunTime Analysis CS > 18ms > PS > 48ms > PE > 43ms > CE
+117ms ║Runtime (36508 bytes) successfully initialized in 48ms (v0.2.0e7.20170906) (115ms)
+118ms ║╔Execution stage started
+137ms ║║Condition #8 evaluated false (9ms)
+139ms ║║Condition group #1 evaluated false (state did not change) (11ms)
+150ms ║║Comparison (enum) on changes_to (string) off = false (1ms)
+153ms ║║Cancelling condition #14’s schedules…
+154ms ║║Condition #14 evaluated false (9ms)
+155ms ║║Cancelling condition #11’s schedules…
+156ms ║║Condition group #11 evaluated false (state changed) (13ms)
+160ms ║╚Execution stage complete. (41ms)
+167ms ╚Event processed successfully (167ms)
