Okay my friend, your loyalty motivated me to help you out quickly, so the latest post now includes a feature that allows multiple things to be controlled in a single HousePanel API call. The feature only works with doaction or dohubitat API calls, not the query equivalents. To use this feature just list multiple thing ID's or TILE numbers in the API call separated by commas. For example:
All commands are supported including on, off, and toggle. The subid and attr parameters are also supported as with all HP API calls.
The return value will be a concatenated string of json variables returned from each of the things. I didn't separate them with a comma - but I probably should have. Let me know if you have a preference. If it is important I could make a valid single json return variable. Note that these returns don't work for the GUI which is fine because the GUI can't generate multi-tile actions anyway.
Ken you are awesome - This seems to work perfect. Thank you!
I think this is what I need - Something that can be easily parsed. Reading this paragraph made me realize something that should have been painfully obvious. I have been using a separate call to update status on my widgets. The widget app I use updates every widget on variable change. I should have been using the response from the original commands. This will simplify keeping everything in sync - I had much more complicated plans to do this.
One last note - I could have sworn I read that you added support for pistons, I well could be wrong on this because I cannot seem to find the post atm - I toggled the option on in the app, but I don't seem to have the option to authorize pistons.
I couldn't remember if the pistons would just show up in my dashboard - So I checked and no dice there either.
Not a huge deal here - I am trying to shut down all my piston anyways. I was really just testing. I well may have missed / messed something. It's after work and I am sleepy
Thanks Chris, I’m happy to have done that. Regarding pistons, I put together hastily an update that I thought would work but I don’t have Pistons installed on my habitat hub, so I will need to do that and then test it to get it to work.
Folks - I'm making progress on the multiple hub feature. The interim feature can be found in the "multihub" branch in the GitHub repo.
This is still beta code and a work in progress but for those living on the edge who want to try it, feel free.
This basically allows any number of hubs to be added and authorized, and it uses the proper OAUTH flow methods for authorizing Hubitat instead of the current hack.
Not expecting anyone to try this, but I did want the community to know that I'm working on it. The importance is bigger than Hubitat. This will enable HousePanel to be a generic panel to talk to basically any hub that supports OAUTH authentication. Next up is Wink. The only requirement will be to write a binding to read things from the authenticated hub. I will work on documenting that profusely.
My goal in posting this now is to build some excitement about HousePanel evolving into a general purpose control panel for any smart home hub. I recently was turned onto OpenHab by a friend. So an OpenHab binding will be coming your way soon too.
Today I posted the a candidate release version of multihub HousePanel to the "multihub" branch in the usual repository. As a reminder, I moved the master repo to my GitHub account so you should be using that one now.
This version 1.793 includes a number of important new features. Most importantly, it has multiple hub support. Any number of Hubitat and SmartThings hubs can be connected to the panel. Hooks are there for Wink and Vera support which will come with time. I'm excited about this because I wrote this generally enough to make future hub bindings easy to add.
Other updates include:
New analog clock (uses the CoolClock javascript plugin)
Music tiles now work on the Hubitat side
Authentication flow on Hubitat now uses standard OAUTH
support both local and cloud end point flow options
the API URL will dictate which version you get
Info page now shows hub details for each connected hub
New graphics included for use in the Tile Editor
Squashed numerous bugs including a long-standing empty page bug
The authorization page is intuitive and easy to use. Once a hub is authorized it will return and tell you how many devices were retrieved. You can then proceed and authorize another hub or return to the main page.
This update implements a new format for the hmoptions.cfg file. Code is included to read and translate old hmoptions.cfg files but it is probably not perfect, so you may need to redo some of your setup.
The rest of the app looks as it always did so I won't post another screen grab here. However, the new graphics and features in the editor are super cool so you should try them out.
A merge to the master branch will occur soon but feel free to try and test this version. It should be pretty stable.
My buddy has one so I am working on coaxing him into helping me get a Wink binding. It isn't there yet but it will be soon. Bindings will be a snap to write with this new architecture. EDIT I looked at the Wink API documentation, and it is very well done. It puts ST's doc to shame and well Hubitat just mooches off of ST so that is even worse. Anyway, I'm just about done with a binding so I think a Wink hub is in my near future. Check out their OAUTH docs here complete with code samples: https://winkapiv2.docs.apiary.io/#reference/oauth/obtain-access-token-from-authorization-code-grant
By the way, I just did the merge with the master branch so grab that if you want to try it out. The merge in the master has your multi-tile API call included while the multihub branch doesn't.
I'm also going to work on an OpenHab binding since that won't cost me anything to do. Vera is the wild card since I know nothing about it.
If so, there may be an issue with loading them. Open a log window and keep it open while you do a reauth. Then you should see an error message. Let me know what that is.
I am not seeing anything in the logs that seem related when doing a reauth.
The motion sensors are coming in from Smartthings but not from habitat.
I am thinking that devices with the capabilities of "MotionSensor, Sensor" are not being populated. If I add "ContactSensor" as a capabilitly to the Konnected Motion sensor code, it does appear.
The motion sensors also do not appear in Hubitat, Apps, Houspanel.groovy in the section under "Motion and Presence"
Okay - I checked and here is what I think is going on. The code supports and reads motion sensors with capability.motionSensor but not capability.motionSensor.Sensor
notice the motion sensor at the end. It works like a motion sensor. I checked the capabilities reference and the official name of the motion capability is just capability.motionSensor so that should work.
Motion sensors are also retrieved using the generic getThing call which returns all capabilities of any thing. I disabled the log which is why you aren't seeing anything. I can re-enable it and post an update for you to try. It will have a few other minor bug fixes too.
What kind of motion sensor are you using?
[EDIT] Update posted to usual spot. Should help with debugging.
Working on a hunch, I looked at the DTH code for the konnected motion sensors. You can ignore my prior question about what type of sensors... I get it now.
Anyway, the motion DTH is an unusual sensor that HP may be struggling to identify. I enabled the code to allow generic other things to be selected. Grab the latest version and you can add the motion sensor as an "other" device. It will look and operate just like a motion sensor.
I’ve downloaded the updated code, reauthed etc, but the motion devices are still not appearing. Maybe I’m doing something wrong. No errors in the logs (Hubitat logs).
Appreciate your help... not urgent or anything.. have many other devices to move over from smartthings in the meantime. Cheers
Did you try to look for them in the Options page? Are they being loaded at all? The default logic might be skipping them yet they might still be there.
Another thing to try is to add them as an Other device. Did you try that?
For what it is worth, motion detectors on a panel have fairly limited use so this thankfully isn't a show stopper, but I still want to know what is going on.
I have been noticing a visual glitch for quite some time now with my door lock.
If I push the tile to lock. The tile icon changes to the locked. Then changes back to unlocked. Then once more to lock and stays.
I am thinking this may have to do with a refresh being called too soon, as the lock actually takes a few seconds to perform the lock action and does not update state until it is complete.
Then again I could be completely wrong. The observation remains the same though
edit: same thing if going in the other direction from locked to unlock.
Hmmm well, some things do need a delay because they report interim status or incorrect states immediately, but locks shouldn't because the logic is a simple toggle. If locked, it returns unlocked and vice versa. I don't even bother reading the lock status - I just set "newsw" to the value it should be, so a delay shouldn't matter. Anyway something odd must be going on. I updated housepanel.js to introduce a delay for locks like I do for doors and music tiles in a branch called 'lockdelay". Can you give this a try and let me know if it helps? It works for me but so does the original. The delay just shows the new state 3 seconds slower. You'll just need to update the .js file.
[EDIT] I realized Hubitat updates all tiles every 5 seconds so that is probably what is happening. You are getting a 5 second update in the middle of a refresh based on an old state. So I'm thinking the delay I implemented might work. Let me know.
