Can't change default/starting value of local variable

#1

1) Give a description of the problem
I’ve got a piston which notifies me if any of my lights turn on and off during the daytime (my kids kept leaving lights on!) and it’s been working perfectly fine. I recently added control to a few more new lights around the house using Fibaro devices and for some strange reason, one of them (Porch lights) seems to have permanently attached itself to the ‘LightsSwitchedOn’ local variable in the piston. This means the local variable always has this light stored in it so everytime certain lights are turned on during the day and I get the notification, it includes the Porch Lights even though they aren’t on.

2) What is the expected behaviour?
I want the LightsSwitchedOn local variable to have no default/starting value and to be cleared once all lights are off so that my notifications are accurate. I also don’t understand what it is about the Porch Lights which is causing them to be wedded to the local variable.

3) What is happening/not happening?
I’ve gone to the variables section at the bottom of the piston and I can see the LightsSwitchedOn variable listed there with a value of ‘Porch Lights’. If I click the little edit button and change the value to ‘Nothing selected’ and then save, nothing happens. It still shows the variable as having value ‘Porch Lights’. So I can’t seem to be able to change the variables default starting value.

I’ve tried deleting the variable, saving the piston and then recreating the piston but as soon as I recreate it, the Porch Lights immediately become stored in the variable.

4) Post a Green Snapshot of the pistonimage

image
image.png1178×743 40.7 KB

#2

I see you’re using a global variable, which is hard to diagnose which devices are associated with it. How about changing it to a local variable, adding your devices there, and seeing how it performs then?

#3

Can do. Reason I put all the lights in a global variable is because I use that in another Piston as well but worth at least testing. But doesn’t explain why the Piston has been working absolutely fine for so long and then suddenly this issue…

#4

Lately, I have seen lots of people trying to use @globals to keep track of devices… but I always discourage against this.

They do it to “save time”, but they do not realize that updating a global does not update the pistons referring to that @global.

Long story short, you can edit and then re-save each and every piston that points to that @global, and the pistons should see your most recent changes.

#5

No luck. This is so frustrating! I’ve deleted the global variable which was storing all my lights and replaced with a local variable in this piston. There was one other piston using that global variable so in that piston I’ve also created a local variable containing all my lights. I’ve then opened up and re-saved all the references to the ‘allLights’ variable in this piston just to make sure there are no broken references. I still can’t stop the other local variable which should store the lights which get turned on (which I’ve now renamed to ‘LightsOn’) automatically and immediately storing the Porch Lights inside it. I’ve tried deleting that local variable and recreating but as soon as I recreate it it adds the Porch Lights to itself! Trying to change the default value of the variable from the piston’s main screen has no effect - I don’t understand what’s going on.

I thought it might be to do with a cache somewhere not being cleared so I even deleted the ‘LightsSwitchedOn’ variable which was the original one and recreated it as ‘LightsOn’ and replaced all the references in the piston but again, those darn Porch Lights just get added to the variable!

Green screenshot of piston:

image
image.png1178×778 43.9 KB

#6

Hmm I think there is something up with the device itself. It’s basically a gen 1 Fibaro single relay module and I’ve set it up with a Custom DTH I found for the relay. In the IDE when I check the properties of this device in the ‘Current States’ section it shows a ‘switch: on’ and a ‘switch1: off’ so that’s odd.

I thought I’ll just change the DTH to the standard one for the Single Switch 2 in case it’s something funny with the custom DTH but once I change the DTH, when I click the update button I get the following error page which I’ve never had:

image
image.png918×406 15.5 KB

#7

All you have to do is a factory reset, and all your problems will seem like a distant memory.

#8

Of the relay? The access denied issue was a Chrome session error so sorted that and can now update the DTH fine. I’ve done that and now that I’ve changed the DTH for the device to the standard Fibaro Single Switch 2 one, it’s showing as on and it’s not responsive in the ST app to turning it off. The usage stats in the app are also blank so I think something is up either with the device or it doesn’t like the Single Switch 2 DTH

#9

Yes factory reset the Fibaro. I doubt it’ll like the Single Switch 2 dth. Just exclude it first by 3 clicks on b button, then factory reset it click until yellow led, then quick click. Include close to the hub, and you can use the default “Z-Wave Switch” dth for local control.

#10

All sorted. I had another custom DTH which I tried on the device and it was showing as on immediately after I updated the DTH even though the lights themselves were off. So I switched it off via the app and then checked the IDE and it correctly showed it state as off. I then reverted the DTH back to the custom one I was originally using and it seemed to be fine and showing the correct state in the IDE when I toggled it on and off.

But I took your suggestion and changed the DTH to the standard ‘Z Wave Switch’ one just because I’d rather use standard DTHs where I can. That also works fine with the relay and when I’ve come back to webcore the variable is now no longer holding Porch Lights as a value and all is good :slight_smile: Looks like something just got itself in knots but glad I finally got it working - was driving me nuts!

Thanks for your help!

#11

Just back on the point of global variables - I thought the fact I needed a variable (in this case the ‘allLights’ one) in more than one piston was the whole reason global variables existed? So that you don’t have to duplicate the same variable as a local one every time.

Is that not the case? Seems a bit inefficient if every time I create a piston which needs to use a variable containing all my lights, I’ll have to create a local one…

#12

I think local variables are definitely more efficient when referring to device lists.
(although personally, I try to avoid putting 22 triggers in the same piston)

Either way, whenever you add a new device, all pistons that reference that light have to be edited anyways.

Plus, if another piston sends a command to turn on {allLights}, there is a good chance that some commands may get lost along the way. (sending out 11 commands in a second is not too reliable) Not to mention, that THIS piston will fire 11 times each time you send a command to {allLights}.

I apologize if I seem negative here, but this path is a recipe for disaster.

#13

Hmm I wish I knew what you meant in terms of improving my Piston design but I have to be honest I have no idea! Is there a Piston doing the same or similar to mine you can point me to which is coded in the right way?

#14

I don’t think there will ever be one “right way”… We all do things a bit differently.

Me personally?

  • I would not use @globals as device lists.
  • I try to avoid multiple triggers in a single piston
  • I rarely group devices, since spam reduces reliability