BETA call for superState scene app (all better now!)

That option isn’t completed at this point. Mentioned that in the first post, want to get base functionality dialed in first.

Yea, I do as well, thanks for the mention.
It’ll be really cool when I get it fixed…
Most issues worked out from the platform and android update, one left…
Fibaro RGBW is working as well now.

@beckwith fibaro now works…
Please update to v1.1 from git link above…

Thanks for the response Mike and seriously great work on this. It’s an extremely cool app even in this BETA state. I was wondering though how you’d recommend uninstalling device groups or light scenes. Currently there isn’t an option in the app and I didn’t see it mentioned in this thread. Is that something that you’re working on as well?

Thanks so much!

The scenes are the issue since they create the virtual switches, the code to delete the child device when its scene is deleted is in there, but commented out.

Uninstalling the app, will delete all the child devices.

I get a permission denied error when deleting the virtual switch that’s associated with a scene, so this looks to be a platform issue which I will start working on with ST.
I’ll also do some more testing to see if there’s a workaround I can find.

UPDATE:, no workaround, however it’s been logged as an issue with the developer that fixed the child device issues a few weeks ago. Shouldn’t be more than a couple of weeks before this gets fixed.

1 Like

I have seen similar things. Seems it sees the “smartapp” there and won’t delete itself.

Just to be a wise guy, I tried to explicitly unsubscribe to the device, prior to calling deleteChildDevce…
No bueno, though the error was much more exciting, and way less helpfull:
org.springframework.dao.InvalidDataAccessApiUsageException: deleted object would be re-saved by cascade (remove deleted object from associations): [physicalgraph.app.EventSubscription#e9ac5fe6-8bb3-488e-9ccc-45ec0c968e0d]; nested exception is org.hibernate.ObjectDeletedException: deleted object would be re-saved by cascade (remove deleted object from associations): [physicalgraph.app.EventSubscription#e9ac5fe6-8bb3-488e-9ccc-45ec0c968e0d] @ line 310

I always love the errors that are like 14 lines long and say nothing… lol

What is the status of that app? It’s exactly what I wish for but it doesn’t seem to be working. I’ve installed the device type and the app. I can create a group and then a couple of scenes. When I take a “snap” the switches I’ve selected turns off. But then when I click the on/off button none of the lights turn on. All the lights are actually Hue bulbs.

Thanks

@reward72
The issue is with the hue’s updating ST. If you’re setting the hues from the hue app, you have to wait for those settings to propagate to ST. When I snap my hues I set them with the ST device tiles, then I don’t have to wait for ST to poll the hues for the current color settings.

Interesting… Ill try that. thanks

1 Like

Hi Mike,

I’m hoping you can help me out! I’ve been using your awesome superState for a while now, but had to reinstall it recently since i had to redo my whole Hue setup just to add a new bulb. Needless to say…it was a pain, haha. But now that I’m trying to resetup your app, but when I set all the lights how I want them and snap to record the state, they all turn off, but when I try to turn that scene on only a couple of the lights will turn back on!

Any ideas? It was working perfectly before so I’m stumped.

Thanks!
Doug

@Doug_Hogan
Are these just the hues giving you issues?
Are you setting the hues via the hue ST device, or via the hue app?

I’m using both Hues and regular switches. It seems to only be able to control 4 to 5 lights for some reason. I think I found a work around however by creating additional device groups. Just wondered if you had run into something simliar at some point!

Thanks!!

@Doug_Hogan
I have 13 devices in one of my groups, 8 hues, one fibarro rgbw and the rest dimmers.
So there’s no built in limit from the apps point of view.
I have noticed from time to time that some of the ones at the end of the list don’t fire.
I suspect when ST is slow, which it was last evening for me when the last one didn’t fire, that the app is timing out.
I can’t do anything about that. When this happens, it should appear in the live logging.
It would be good to know if that’s the case, though the only fix would be V2, which would make the whole app much faster.
I’ll fire up live logging tonight and see if I get the app execution timeout, if you do the same, maybe we can narrow this down.
Mike

@Mike_Maxwell Same situation here 11 hues and family in one group. But lately at least 10 of them gets turned on (no pun intended) and 1 is always a miss but it is arbitrary. Not necessarily the last one.

Great app! I have some BR30s that turn on and off as expected, but my living colors light (the flood light looking one) won’t turn on. It turns off, but I can’t turn it back on via the virtual switch. Any advice?

I have a Living Color in one of my scenes, and it works as expected.

Only thing I can think of is that the state of that living color (from ST’s POV) was Off when the scene was snapped.

When I set scenes that include hues, i set the hues with ST (not any hue apps), that way I don’t have to wait for ST to poll the hues for their current state…

I wish that the hue integration provided dynamic updates to ST when hues are set via their native apps, but such is not the case.

superState can only snap the current device state as currently know by ST, this should also be the actual device state, but as we know this isn’t always the case.

I just kept trying snap and it finally took. Weird…

Anyway, nice app! I’ve been looking for a better way to manage my scenes.

glad it worked out, this app is fighting the cloud so to speak…
It should be ripping fast when run from a V2 hub.