Piezo beep (Entry/Exit delay). Strange behavior


#1

I have a Konnected system that’s working well and just added a Piezo buzzer to the setup. We also use a Kindle Fire HD 10 tablet and Actiontiles for the interface to it all. The Piezo, as per Konnected Support, is set up as a light device that beeps.

We wanted to emulate a typical security panel that, upon entry to an armed system, would beep repeatedly and also speed up as it nears the timeout. Our piezo is setup to beep, pause, and beep very much like the typical chirp you get on a traditional security panel when you open a door. In code we have it do this beat, then pause for three seconds, then repeat. Then, after a period switch to a 1 second delay.

It’s more or less working, but we’re getting one odd anomaly we can resolve. It will do the long beep and then go to the short beep, do it four times, then hiccup (no sound) and then beep 9 times, hiccup, 9 times, hiccup, repeat forever until we stop it.

What process would cause this reliable drop out?


Best Approach for Audible Countdown for Entry/Exit (with SHM Delay app)
#2

Can you paste logs from when it’s getting stuck?


#3

I made slight adjustments to the code so that the debug logging statements would be a bit more specific/useful and then replicated the issue a few times so that I could get the best sense of whats happening and relay it to you here.

So it turns out that there is a pattern/consistency to the issue that unfortunately is looking like it might just be a limitation of webCoRE not being able to work for something that is this “demanding”/timing critical. The code itself works 100% fine, but what happens is that every time webCoRE hits the next interval of dumping its logs (it seems like its about every 10 seconds and I’m guessing this is hard-coded behavior) the whole system seems to choke and that is when the unwanted delay happens. Essentially, it appears that webCoRE can’t post its logs asynchronously or on its own thread.

You can see this clearly in the log, which I’ve linked at the end of the post. To make it even more obvious where the problem lies I rearranged the logs to be completely chronological (I don’t understand why they’re printed in the fashion they are), calculated the delay between each piezo beep, and marked each delay on the logs themselves:

As you can clearly see the extended delay occurs every time that webCoRe pauses to dump the next set of logs. To see if this was slowdown sheerly due to the fact I was printing debug info for this piston, similar to using the expensive printf in any real language, I tried removing all of the logging statements from the piston, turning off the trace button, and closing the browser tab for that piston that was monitoring it yet the problem is still present, exactly the same.

Like I said previously, I have linked the full logs if you need to see anything else, but the above picture pretty much covers it. Again, it seems to me that unless there is a way to customize how webCoRE handles logging that this is simply a limitation that can’t be worked around except by jury rigging the crap out of my piston code so that it accounts for this delay every 10 seconds, which would also limit how quickly I could beep the piezo and is overall just non-viable.

Full Logs: https://pastebin.com/MBzEWGa5


#4

What is “Switch 4”? Trying to understand how your piston works.


#5

Sorry. That’s just a device that gets turned on when the alarm is triggered. Its turned off when the system is disarmed after an alarm trigger

I called it “Fuse” since its like a fuse burning when the alarm goes off


#6

No ideas anyone?


#7

Really late getting back to this, but a related thread seems to have ID’d the limitation within the SmartThings environment:

Did you ever come up with a satisfactory workaround for this?


#8

Working on one now :sunglasses: