Oh, and if it helps, I was going to report to you that the issue you had and many have had, myself included, may be alleviated by creating a CoRE notification that sends you a notification when SHM reports Disarmed.
I set this up a few days ago and removed my I’m Back notification - I don’t care when it executes, I care to confirm SHM actually disarmed.
I still believe this would fix most of these issues. Like 99% of them, so you can bask in the glory amongst gods like @bridaus and @bamarayne - our resident 99 percenters. In fact, legend has it bridaus may actually be operating at 106.98773% and rising.
If you arm your SHM when your hub has internet connectivity, and then prevent internet traffic. Disarm SHM from your mobile, SHM reports back as disarmed.This isn’t viewing status of SHM in the mobile, this is CoRE reporting back that the system indicates at that level it is in fact disarmed. That was an experience I had today while testing something else.
Where does that leave the state of localized SHM routines? Well, one can only presume they will continue as if armed.
So the confirmations that SHM was disarmed may not be as valuable as one may have thought.
Contact sensors not reporting since last night at 1:56 am.
Is anyone else having this problem my iris keypads and my contact sensors stopped communicating last night. I first noticed I couldn’t arm my alarm with the keypad. Then noticed front door showed open. I tried doing a reset and removed battery still no luck. After a full reset of the HuB still no luck. I then noticed it wasn’t just the front door but numerous contact sensor will not communicate. Removing battery and trying to reset will not help. Is it possible I have this many bad devices at the same time?
Is there something I can try or should I just wait it out and see if it fixes its self. I also noticed my ge wink bulbs that I have had over a year with little or none disconnect issues but just in the last week I am resetting bulbs on a daily basses. Do the bulbs go bad after time? Should I just by bulbs that are supported?
My personal experience with GE link bulbs has been awful. I started out with eight of them and eventually ended up replacing all of them with Hue whites ( connected to a hue bridge) and all of my bulb problems went away then. I know there are other people using them successfully, but there are a lot of people who have problems as well.
So you may have two separate problems, the bulbs and then schedules failing, which seems to be new this week.
If it was me, I would report the schedule problems to support and get rid of the bulbs.
@Richy - If you haven’t already, please send a note to support with your account information and the approximate time when the automations failed. We’ll look into this right away.
(Jason "The Enabler" as deemed so by @Smart)
I agree with @JDRoberts on the bulb use. I started out with around 30 of the GE bulbs… hated them. Once the hue whites dropped in orifice i replaced all of my bulbs and the problems have gone away. It actually cleared up done of my zigbee issues as well.
Think generally speaking that direct attached zigbee bulbs are not great in Smartthings. As they’re powered, they integrate into the mesh but apparently their capabilities are very limited and end up causing problems relaying to others in the mesh. The more zigbee devices you have relying on this the bigger the problem gets.
According to ST engineering staff, the repeater problem seems to be specific to some brands. At least they haven’t seen any problems with the Cree bulbs in their own testing. They have seen it with Osram, WeMo, and GE. But GE has yet another problem, which is just dropping off the network.
Wow, thanks James, that is helpful. I like the things you came up with. I can see using a Vantage Switch and Dimmer and maybe a Group. I don’t have any sensors tied into the system. Adding devices to the system is less expensive with ST than with Vantage and easier to setup (no call to the installer). BTW: I have an InFusion system and it talks over Ethernet but I think the commands are the same or similar to QLink.
Just now I am finally able to create a SmartApp that commands a button without my WebAPI. It uses TCP and sends BTN 82 which toggles button 82 (my study All On button). I also am able to toggle loads and to set load values (0-100%). For now, I am unable to get return values but hopefully I can figure that out.
Regarding, virtual buttons on the Vantage side - I have things like that although they are just Vantage tasks. A task, a button, a load, they all have a unique VID in Vantage so they can all be commanded through the interface. Most of them are triggered by some other button press on the system or by time of day. I created a virtual switch in ST to turn on/off a Vantage load but I could just as easily trigger a Vantage task. They are easy to create in Vantage so I agree with you that developing Vantage tasks just for ST to command is a good approach.
Did you develop anything that scans your Vantage system from ST so user can browse devices? I don’t see a single command for Vantage that returns a complete list of devices but it seems I can ask for information about a particular VID. So it may take multiple calls with an app that simply asks for VIDs 0 - 999 - seems that could take too long.
Any chance you would be willing to share your device handlers with me? I’ve tried looking at others but I struggle with how to apply them to my use case. I suspect yours will be the closest to my use case as possible.