I’d like to write a device handler that asks for a temperature sensor device and a thermostat device and then displays the combined information as a thermostat device and allows you to change setpoints. Then I could use the keep me cozy II smartapp to change the real thermostat (possibly this will need modifications, too).
The reason I’d like to create this as a device handler is that then it will look like a regular thermostat and be able to show up in things like Smart Tiles - much easier for people to change the target temperature, etc.
However, I’m stuck trying to display the temps from both of the devices in the new virtual device.
I have:
preferences {
section("Choose temperature sensor to use instead of the thermostat’s… ") {
input “tempSensor”, “capability.temperatureMeasurement”, title: “Temp Sensor”, required: true
}
and I’m trying to just log.debug the temperatures:
log.debug “TempSensor Temp: $tempSensor.temperature - Controlled Thermostat Temp: $controlledThermostat.temperature”
To be fair, all of the logic was going to be in the smartapp. I was using the device handler (how come it was so much easier to type “type”?) just for the interface since smartapps don’t have USER interfaces - they only have maintenance ones.
A better example of what I was trying to do is a “Door” It should be able to have two parts - Open/Closed and Locked/Unlocked. All in one user interface. A regular user doesn’t care that it is two different pieces of circuitry- they think of it as a door and would respond better to it that way. Also, it would cut down on the clutter - there seems to be a lot of pieces floating about.
The Room concept was a start. If the Room could be designed like a device is now - with tiles that could be arranged instead of just a list. Also you’d want drill-down: House would drill down into Level which could have rooms which could have a Door which could have a Lock and an Open/Close. Smart Tiles starts the way down that path but it is crippled by only 5 “areas” total - I’d probably want somewhere around 20 - and the lack of an interface for SmartApps. Another option would be able to swipe/tap between areas in a Level, etc. from a list at the top (like you can now from the aptly hard-coded named “My House” where you swipe between Rooms, Things, SmartApps, and Family.
A bit off the original question I asked but it gives a bit of context into what I was attempting to accomplish.
[quote=“dmw999, post:5, topic:35991”]
A better example of what I was trying to do is a “Door” It should be able to have two parts - Open/Closed and Locked/Unlocked. All in one user interface. A regular user doesn’t care that it is two different pieces of circuitry- they think of it as a door and would respond better to it that way. Also, it would cut down on the clutter - there seems to be a lot of pieces floating about.
[/quote]There used to be doors in the old app that did exactly this. You could do neat stuff like “lock a door after x minutes closed and unlocked.” They disappeared in the new app. Am I mis-remembering that there was a promise that they would return?
There was a section or group called “Doors” it was a list of either locks or open/closed, if I remember correctly. However, it didn’t combine the locks and open/closed into 1 door - at least I don’t remember it doing that.
In the “old” (pre v2 hub) version, we had Doors & Locks. You could pair a door contact sensor and a lock and you’d get a “Door” which would have states like “closed and unlocked” or “closed and locked”
I did something similar to make a “Garage Door” device type out of a contact sensor and a relay switch. I wrote a device type that shows the open/closed status of the door as well as actuate it when you press the icon. I then use a Smart App that is the glue between my virtual garage door device and the individual contact sensor and relay. So the user interacts with the virtual device that generates events that the smart app subscribes to and then sends out commands to the real relay switch. Likewise the app subscribes to the contact sensor and when it changes state, the app sends commands to the virtual device type so it can update the icon.
SmartThings device model is very primitive and inflexible. On one hand, you have devices with multiple attributes, like multi-sensor for example, that cannot be unbundled and displayed as individual sensors. On the other hand, you cannot combine multiple sensors/actuators into a complex logical device with common user interface. I won’t even talk about incomplete and inconsistent device attribute taxonomy (a.k.a. “capabilities”) which was discussed many times before. The system just wasn’t designed with complexity and flexibility in mind.
So, if you think about it. You need a “deviceType” to be the “hub” device. This device relays the info to the smartapp then the smartapp can use that data to then spawn child devices, etc.
Check out how the Hue Connect, Hue Bridge and Hue Bulbs work for a good model albeit not perfect model.
Right. I was trying looking at the Nest one as a starting point but that it really a different animal, I guess. Thanks for the pointer.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
15
You can… Using a Virtual Device (of any sort of customized fantastic mutant conglomerate type that wish to create) and one or more SmartApps that feed it with data from more basic real Devices.
It’s reasonable this way; but SmartThings clearly knows they can extend this and further abstract it and make it more integral (at least in the App) via the Shortcuts and similar “Dashboard Solutions” – that were yanked for App V2 and will (?) come back in some form or another…
Yeah, right. It’s not a solution, but a kludge and a sure way to create a horrible mess where a physical device is represented and controlled by multiple device handler. And the worst part is that you need a smart app to glue your virtual device to the real ones. If it were done right, you’d be able to create a virtual device by simply referencing attributes from other devices.
but SmartThings clearly knows they can extend this and further abstract it and make it more integral
Clear to whom? I see no evidence of this being the case.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
17
The “Dashboard” portion of the App is front-and-center (literally the “home page”) and did not exist in the initial versions of the App. I forget when it first appeared … I think Version 1.4?
This was created to make up for the shortfalls of the existing two options: Things and SmartApps.
The UX team must have got together and said we need a place that creates the Dashboard Solution Pages we that were introduced at that time (Damage & Danger, Doors & Locks, Lights & Switches). This concept, as far as I know, was completely absent from the original architecture.
Somewhere during the V2 design process, however, someone decided that all of the existing Dashboard Solutions were too confusing or too inefficient or did not fit with the new look & feel of the sole new and surviving Solution: SHM.
The Dashboard page, itself, still exists, and we’re told in multiple threads that it will be populated with more “Solution Modules” – and that Community Developed solutions, sometime, someday, might also get to appear on this page. Take note … Smart Home Monitorruns perfectly well on App V1!!!
Solution Modules are just SmartApps built with some features that are not (currently?) available to us. Those features help abstract the user from the complexity / confusion of “Virtual Devices”, without requiring SmartThings to change the fundamental underlying architecture.
Well, the scenario here is to have parent-child device handlers in order to consolidate the USER UI. The issue is that SmartApps do not have a USER interface - they only have a maintenance interface. You absolutely don’t want to turn a casual user loose with the ability to change what things are connected together, etc. when all they should be able to do is change the target temperature, for example.
The Virtual Thermostat smartapp is a perfect example of something that is fully functional but completely end-user unusable. No end user (i.e. not the person managing the site) should be able to change what is connected to what and how things are controlled. The interface needs to be like the device handler for a thermostat - see the various pieces of information in one place and graphically and only be able change a few things with the rest locked down and not readily accessible to change. One straightforward screen. You CANNOT merge configuration and usage scenarios - that is basic to any proper user experience.
Perhaps the Solution Module will have a USER interface capability - I guess that Smart Home Monitor is more along the lines of a user style interface. Is there any eta for the rollout of how this could be used or even a few more easy examples that could be published? For instance the Door with open and locked statuses (again, graphically with colors and specifiable, not a list) and a thermostat with a remote sensor merged together would be real good examples and starting points. Heck, even a temp sensor and a switch to make a Thermostat - a la Virtual Thermostat with a UI, emphasis on the “U” - would be good.
Is there going to be a way to restrict some users in a site so that they cannot go into the configuration areas for things or smartapps? It has been awhile since I setup another user but I don’t remember that kind of capability anywhere - I could be mistaken.
This is the kind of stuff that changes things from an enthusiast/hobbyist level to a consumer level.
@dmw999, I would be happy to, but the ones @pstuart mentioned in post #13 are probably better. I only say that because the “relay switch” device I have is one I build with an arduino and thingshield, so it already had a custom device type that I wrote earlier. which makes it harder to follow. But if you still want to see it, let me know.
