Battery Alerts (Setting Conditions)


#1

Okay, I’m humming along myself creating brand new pistons. Very nice app.

Now I ran into a confusing issue for a noob.

I want to create battery alerts for my battery-driven devices. So, first question:

Should I create one piston for each device or one piston with each device within it? If the latter, what sort of logic should I look to? I assume I’ll need some sort of variable use to say something like, "If Lock then Device$ = “Lock” so that I can then send a notification (via e-mail or SMS) that says “The battery in the LOCK is low” by passing, “The battery is the " + DEVICE$ + " is low.”

Second, the conditions create a dilemma. If I say something like,

IF Basement Water Sensor battery is equal to or less than 10% then send SMS…

… then I’m confused as to how that stops running as it stays at 10% and drops to 9%, 6%, etc. Seems as if I’d get a notification continuously from then on.


#2

Here is something I use.
It gives me a notification once a week.
You can alter this if you wish.
All my battery devices are defined in the global variable @batterydevices.


#3

Bob,

Thanks for this. Now I’d like to start to decipher it and put it to use.

Can you fill me in on the following:

  1. What’s the benefit of “disable automatic piston state;”?
  2. What’s the benefit of “disable command optimization;”?
  3. Why do you need to define the two device variables?
  4. Where do you actually store the battery devices? I see you say they’re in a global variable, @battery devices, but how does that work? How do I set one up like that?

Thanks.


#4

When you look at the dashboard you can see all your pistons listed. They will show mostly True or False in light grey.
By disabling piston state you are able to input a personal message. In the piston you will see Set Piston State. What is in the text will now appear in the piston list. See below:-
image

Command optimisation being disabled means that the, lets say, On or Off command will be sent regardless of the device state. If it is enabled and a light is on then if a pistons evaluates to turn a light on and it is already on, it will not send the command. This doesn’t need to be disabled for this piston but I have stateless devices in my setup so ST does not know if they are on or off so I force the command to be sent regardless of the device state. Probably got set to this when i did some duplication of pistons and forgot to set it back. Doesn’t matter though.

I just decided to have 2. One for a warning to let me know that batteries are starting to get low and another to warn me that I might like to change the batteries for these particular devices. One will do if that is what you want. Again, just something I decided to do.

The battery devices are stored in a global variable so that they can be used in any piston if I wish to. If it’s a local variable then it can only be used in this piston.
To define a global variable, open a piston in edit mode.
Scroll down or look across to the right side pain and you will the variables listed. You define a global variable here by clicking on this -
image
In the new window select ‘Device’ as this is a device variable we are defining.
Name your variable.
If you want to select all your battery devices, type :battery in the physical device window and all the devices that you have defined in webcore under battery devices will now appear. Just select all and they save and they will all be defined in that variable.


#5

Awesome help. Much appreciated.

So I started typing this in manually, but it got a bit deep so I went for the restore backup approach and set my global variables. It all looks good minus two issues.

On saving it I get these responses:

“This piston does not subscribe to any events. Unless executed by other means, it will never run on its own.”

I have it set to run on Friday at 8:00am. Everything else I left the same.

+323ms ║An error has occurred while subscribing: java.lang.NullPointerException: Cannot get property ‘v’ on null object

No idea what property “v” is. My global devices are:

Samsung Water Sensor
A Dry Sensor (for Doorbell alert)
Front Door Lock (Kwikset)
Two Samsung Multipurpose Sensors.


#6

If you could click on the green camera and post the screenshot here, it may be easier to troubleshoot.


#7

Here’s a full image of the IDE including the variables. Let me know if that’s not readable.


#8

Your global variable is @batterydevice but in your piston you have @batterydevices.


#9

Thanks Bob. That seems to have done it. We’ll see on the check date/time. I feel like I’m back in 1985 with slight mistakes causing my hours of code to fail.


#10

By the way, if you don’t mind:

Where does a PUSH Notification go? I assume it gets sent to wherever I have ST’s app running (in this case, my phone)?

Where is “Messages”?

Also, even though the piston hasn’t run yet, when I now view it, the COMMENT area next to Define/Device gets filled in with “High” items (two of them) and “Low” items (one of them). How did that happen? Very nice feature, just want to understand it.

Lastly, is this section correct? You have {@batterydevices}'s battery is inside of range 70% and 40%… then essentially save it to “BatteryLevelHigh” (not sure what the heck the X-sub2 is there yet). This line raises two questions: One, what if a battery level is above 70%? Isn’t that also high? Second, lower down you then PUSH text that the state is between 40 and 60%. Shouldn’t that be 70%?

I’m guessing from what I’m seeing here that you’re reporting devices that are no longer above 70% (and thus not to worry about), and those in the middle get reported so that you have some warning. Then finally a push for those items that are in critical battery state. Correct?


#11

Correct. If you have a partner,family etc. and they have ST loaded using your hub they will get it as well.
In the settings you can load contacts and specify which contact it gets send to.

Do you mean store in messages?If so they will appear in the notifications on your phone etc.

It must have run at some time for there to be anything stored in the variable.

This is just an icon for the variable. When you edit a piston, at the top you will see that symbol.

I suppose it’s down to interpretation by me. If it is above 70% I don’t want to know. I don’t want every battery reporting it battery level until it drops below 70%. My reverse logic I suppose. Just change it to whatever makes sense to you.

Yes it should well spotted. Never got round to changing it. Will do now though. :smile:

Spot on.
It all makes sense to my warped mind. :wink:


#12

Just getting started with WebCore, but really enjoying the power it gives to ST. This was one of the first projects I jumped on - so thought I would share my version of what I borrowed from bobbles. Sorry for the bump from a year ago but seems like an obvious first project for any newbies. Included my email expression since I had trouble with line feeds that didn’t work with \n as expected.

I started using global variables for all my devices, so if I change out a device I only need to make modifications to the global definition.

Email body example:


#13

Just wanted to thank @bobbles. Like others, I am new to Webcore and was looking for a piston to do exactly this. I hadn’t done anything with variables yet and I was playing around trying to make my own piston, when I stumbled upon your example. I was able to copy it and then make some changes to the time and battery level conditions so I could test it. It works great. It is so much easier to go through existing code and try to understand what is being done, than to try to create it yourself, at least for a newbie.

I do have one question, when I was trying to create my own code, I had 1 sensor that was reporting 1% battery level in the SmartThings app. When I created my code to inform me of an sensor that had a battery level of less than 50%, this sensor did not trigger the condition. I think this sensor had been at 1% for several weeks and perhaps the 1% reporting in the app was really the dying breathe of that sensor and it was really off-line. I replaced the battery and the sensor now reports at 100%. So my question is: would this piston capture the situation where a sensor is dead and not reporting? I know it should capture it as the battery level decreases, but if something were to happen and the battery went from 71% to dead in just a couple of days, would this capture that?

Thanks again for your work on this.