tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
21
Pride is one of the deadly sins ā¦
Regardless, whether via cognitive dissonance or genuine accomplishment within the duties assigned, clever bits and pieces, or effort above expectations⦠I certainly donāt believe folks at SmartThings are āashamedā or ambivalent of their work; even if objectively some perhaps could be.
To be back on Topic, the objective observation is that Community Developers seem much more willing to step up and fill in the gaps and even take extraordinary accountability for things outside their control. Perhaps itās because our ājobsā arenāt on the line? Or because weāre doing this work for nothing but fun⦠Or pride?
Letās say this Arduino scheduling device idea works⦠It would, in fact, take some significant swallowing of pride for SmartThings to actually admit and seriously consider that it might actually be a feasible, pragmatic and āoutside the boxā solution to mass produce and sell this as add on device⦠As crazy as it seems.
What else can explain the reluctance for SmartThings Management to commit to radical solutions to obvious weaknesses? Oh⦠Thatās right⦠This is a Beta platform, so functionality like Rule Machine, Web client, and reliable scheduling is inconsequential for an indefinitely long time.
Well⦠The ability to run Rule Machine, SmartTiles, and the very likely feasibility of this "local scheduling device hack " is a source of amazement. Something someone can be proud of.
[quote=ābravenel, post:1, topic:38398ā]
but it is heartbeat timing that is rock solid.
[/quote]I setup my Arduino board and ThingShield last night, made the DH log everything it parses, and noticed that itās logging āpingā every 63 seconds.
I created a sketch that sends ātickā every 57 seconds and made my DH into a momentary switch that gets triggered exactly every 60 seconds.
I left the debugging window open all night and I was pleased to find that it was still running this morning, but every hour itās randomly skipping 2-3 āpingā and ātickā events.
Do you think this is a problem with the way I have things configured or just part of ST instability?
Either way this is still 100 times more reliable than the built in scheduling, but Iāve never used Arduino before so I just want to make sure I didnāt do something wrong.
FYI: I bought my genuine Arduino Uno R3 board and SmartThing Shield about 1 month ago and I only spent $55.
This is most likely lag in the cloud. When I first set this up I did the same thing, leave the logs on. Iād see little storms of delays between when the zigbee message arrives, and when it got to a smartapp subscribed to the switch event. You can watch the two logs side by side to see the effect.
[quote=ābravenel, post:23, topic:38398ā]
Iād see little storms of delays between when the zigbee message arrives, and when it got to a smartapp subscribed to the switch event.
[/quote]The interval in which the events are being logged has been consistent. Iām concerned about the 4-6 events every hour that ST doesnāt log at all.
[quote=ābravenel, post:27, topic:38398ā]
Isnāt the ST cloud just great?
[/quote]At least with your solution, Iāll no longer be at the mercy of ST scheduling and when it does skip events, it will just delay things by a minute or 2.
I set up an Arduino in much the same way. Apps can subscribe to different time resolutions from 1 to 60 minutes. I connected it to a PC so that the time is synced with the actual time (currently updated hourly, off by a few seconds by the end of the hour). I also added the ability for the PC to send other data to the Device so that other apps that need to respond at specific times can subscribe and fire appropriately.
I also use a virtual switch that apps subscribe to that is kicked periodically by IFTTT. Those app work too.
@bravenel I pretty much donāt use scheduling, but I have just tested something similar, but used my ASUS router to run a script via a cron schedule to trigger a virtual switch.
In my case nothing new is needed to be purchased. But cool idea. Cheers for that
I have an app that turns on a switch every 15 minutes and then turns it off a minute later. I modified the application to use my new Arduino deviceās momentary switch that fireās every minute instead of the ST runIn and runEvery commands and itās been working flawlessly for 16+ hours.
Edit: Itās been over 9 Days and itās still running and hasnāt skipped a single interval.
[quote=ābravenel, post:1, topic:38398ā]
This is not clock resolution timing, for sure; but it is heartbeat timing that is rock solid.
[/quote]I found a way to use RM to run things at a specific date and/or time that uses the arduino device instead of ST scheduling. Itās a horrible solution thatās really hacky, but it works great.
Hereās my solution:
I made the DH support the Energy Meter and Power Meter capabilities. Every minute, it sends a power event with the current date/time formatted as yyyyMMddHHmm and it also sends an energy event with the time formatted as HHmm.
If I want to turn on a light every day at 4:15 PM, all I have to do is setup a >= 1615 Energy Meter condition in RM.
I have an appointment Wednesday morning so I want the house to play an audio message on Tuesday at 8:30pm. I can easily make that happen by creating a >= 201602092030 Power Meter condition.
I also added value tiles to the DH and labeled them āDate(power)ā and āTime(energy)ā so I wonāt forget what each capability reports.
I canāt thank you enough for providing the detailed explanation of how you implemented the heartbeat functionality because I never would have thought of using arduino to solve the scheduling problems.
I know you are still majorly p%$$ed about STās reliability. I am to a point, but i look around now and the community IMHO is beginning to carry the ball that ST have set down⦠this platform IMHO all though buggy is one of the most flexible. and i look around a lot at the alternatives and they just are not up to the level of flexibility of ST IMO. and on top of that i am learning every day what i can can do to work around the deficiencies of ST and improve reliabilityā¦which i know you want to achieve out of the boxā¦the more i look though i figure i dont want that to happen, i would love to start up a business working with HA, and what better way to go around fixing ST installations where the owners are at the end of their tether and willing to pay me to resolve?
I find SmartThings frustrating as a hobby, I just canāt imagine doing something like that for a living. It would drive me nuts. If you do it as a business, you have to offer some kind of a warranty. Now, how can you do that if they keep breaking stuff on a daily basis? Particularly, stuff that you cannot possibly fix on user end. Youād be out of business in six month.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
35
I think that people would be willing to pay more for technology. Also You have the perfect scapegoat ST. Itās not my fault they broke it again, Sure I can come fix it for another $75/hr. Actually this could be very very profitable if the customer chooses ST against your recommendation and they pay hourly. Talk about never ending revenue stream!
No arguments there! ha
In all seriousness though, and back on topic. The fact that these workarounds for stās deficiencies are even possible is the reason why I donāt see myself ceasing to use this productā¦
Well, Its important to make sure you have a solid agreement before you do anything. BEST PRACTICES!!! are very important. Good product choice is very important. I have learned over time to make things as efficient as possible and minimize and eliminate re-visits etc. Initial Install - 30 day follow up - 60 day final follow up via e-mail works pretty well, with all non-configuration related issues directed to ST.
So, Iām curiousā¦I read about these scheduling issues all the time and I donāt experience them. I have a pretty extensive setup with over 80 devices, lots of apps, a lot of custom DHs, etc. which include many routines and apps configured for scheduled activities. Based on what I can guess about the ST cloud environment I donāt think thereās anything special about my account given that I experience the same outages and upgrades as everyone else. Is it possible something in my setup is keeping my stuff in sync (Pollster or something)? Based on the fact that a device āpingingā ST (via a virtual switch) keeps it in sync I would guess that maybe the sheer number of devices/apps/routines in my environment would keep time flowing but I would guess that a number of you have many devices also based on your posts here.
Seems like there must be a difference, right? Not sure how to go about figuring out what the difference isā¦