Z-Wave Smart Fan Control Custom Device Type

Devices & Integrations Community Created Drivers
,
1

Z-Wave Smart Fan Control Custom Device Type

Update: 08/10/2017 - Updated Github URL.
Update: 10/09/2015 - Updated Tile Layout.
Update: 10/19/2015 - Fixed Current Speed Highlighting on Android. Fixed bug in integer/string comparison that resulted in possibly highlighting the wrong speed. Added “Adjusting” highlighting of selected speed. Code cleanup.

Pasted image317×556 86.5 KB
Pasted image315×554 38.4 KB

Hello Everyone, I’m a new SmartThings V2 owner and my first adventure into any type of Home Automation. There has been some ups and downs, and findings of how lacking device type controls are. I purchased a GE 12730 Z-Wave Smart Fan Control and how disappointing is it that even in a V2 version of the hub that there is not really a Fan Control Device Type. The Dimmer Switch does not do Fan Control like what Fan Control should be like, the funny thing is… these devices are not even new! Why such a poor device type, or rather lack of one for them.

In any case, off i went in search of anything and came across @johnconstantelo contribution. Including @Sticks18 's posts on some tile coloring how to ideas.

Right off the bat the Device Type was miles better for Fan Control. But it had its bugs, fan speed status would not stick, it would revert back to always reporting high even though that was not the case, when digging deeper there were other bugs as well that needed to be addressed. Including the problems with how it responded if the Switch was physically changed and how it reported in the app.

I worked out all these problems and re-wrote it to also include user set input for low/med/high values. The main reason was that the values John had were not the exact same values that were for me, I’m not sure if they are depended on the switch or the fan but either case, it had to be adjustable for everybody. *(Its currently thought its depended on the switch and can vary between models)

So this new Device Type includes Preferences Values for low/med/high, it also will always report correct as to the status of the fan, it also has a ADJUSTING state which is inbetween commands. It is colored, also the low/med/high tiles will be highlighted accurately to the current status. It works great from the app or even if physically using the button to switch.

I left in the slider at the bottom so that you can use it to figure out what your low/med/high values should be, basically start close to the defaults and move one at a time till you hear your fan kick to the next level. You want the MAX level the fan can be at BEFORE it kicks over. Normally High should always be 99, but i left it in and adjustable for the heck of it. So all you have to find is low/med. If you enter nothing the defaults will be 33/67/99

Yes, i purposely left the bottom left fan% even in off state so i can see what it was set to. It also gives you an idea of what the physical button sets the fan to when you do it manually (holding up or down to adjust speed).

Hope everyone likes and can now build on this one as we all continue to make SmartThingsBetter :stuck_out_tongue:

13 Likes
2

Preferences Page - Maybe these should be Called Max instead of Threshold? Low Max, Medium Max, High Max? What you think…

3

Very nice contributions to the device type. ST can’t keep up with adding device types, so we help a lot :wink: but they do catch up.

The ranges I selected were based on watching 1% incremental changes until the switch changed, not the fan. I just monitored the LED for when it blinked to identify the speed change. I wonder if GE changed ranges at some point during production if yours is different.

I still use my original device type, but I’ll give this one a try too.

4

A year and still no fan type is pretty slow on catching up, now that hub v2 is out they need to devote a few resources on doing nothing but revamping these devices types. :stuck_out_tongue:

My numbers were based on when the FAN actually changed from low/med/high using the 1% incremental method. I’m not sure if it also triggered the blinking led, i’ll have to check later today, but i’m suspecting it was, meaning its switch based, and our values are indeed different. All i know right now is those values are when my actual fan kicks to the next speeds. It was the reason I thought we need those values easily configurable since they could be different and were different in my case. When physically using the button to cycle low/med/high it would also produce different values. So low for example could be 11% it could be 22%, its like the physical switch just randomly jumped to a percentage within a range. You can notice this by watching the App now as it will report the current “dimmer” value. So the way I’ve done it, with you defining the switch low/med/high values gives it the ranges that will accurately report what the fan is running at. If you know your fan values are accurate then be sure to go into the Edit and set your numbers to your values. :wink:

No idea if GE Changed up its values, but I noticed yours was the JA and mine was the GE, although they should technically be the same, i’ve read the differences is mainly marketing with the JA going to contractors/installers and GE for more of a consumer packaging. But there might be other changes…

I’ll know soon if those values are Switch Based or Fan Based as I’m now going to order more, my willingness to buying more devices have been based on how great the app to control it is. Now that the App is more functional, I now want more Fan Controllers! :smiley:

5

Nice job on this. I’m still using @johnconstantelo 's values, but I’ll have a look at this also. Innovation is good!

A small suggestion…
You might find it more useful (and clutter-free) to remove the % display and slider and replace it with text displaying the current setting (even when off). Easily accomplished as follows. Change SECONDARY_CONTROL to display status text:

	tileAttribute ("statusText", key: "SECONDARY_CONTROL") {
   			attributeState "statusText", label:'${currentValue}'       		
	}

then add your status text in the parse section:

def statusTextmsg = ""
statusTextmsg = "Current fan speed setting is ${device.currentState('currentSpeed').value}."
sendEvent("name":"statusText", "value":statusTextmsg)
log.debug statusTextmsg

log.debug "Parse returned ${result?.descriptionText}"
result

which results in (at least on Android):

Screenshot_2015-10-09-08-06-53.png540×960 61.7 KB

Note that this also requires you change your PRIMARY_CONTROL from device.currentState to device.switch. This last bit may break some of your custom coloring during state changes. I dunno, since it renders differently between iOS and Android.

6

I have to agree, great contribution. I really like the changes that you have made.

7

So please forgive the ignorance of a new user, and if you can point me in the right direction I would appreciate it, but where and how does a person add custom device types?

How would I get this and add them to my V2 hub/app?

Thanks for the insight

Don

8

Thanks for the suggestions, but I’ve seen the version changes you mention and i’ve purposely changed it. Hopefully you might see that its for the better :slight_smile: So i didn’t see a need to say with text that the fan is on medium, the primary control says what it is, in large letters. Second, since i highlight the actual low/med/high buttons, thats another indicator what it is running at. So having a 3rd didn’t make sense. What I DID need though was to know what values the “dimmer” was being set to. See when you press a button on the app to set speed, it is going to the defined speed, so say medium is set to 67, you press it, and boom your “dimmer” is set to 67, but if you use the physical button, and hold paddle up or down, you will notice completely different values the physical button sets it to, and i’ve tested it alot, it gives just random values within ranges. In any case, i wanted to be aware of what this value was. The SLIDER was left in place just to help with finding out what values your fan should use. Might see if i can just have the preference page auto update the fan, so you can find find the values that way, so no slider needed. But not sure how well that will work.

Hopefully that explains the reasons behind the textual changes. :smiley:

9

But only in the “on” state, thus why I added it.

@dsclarke, custom device types and smartapps are added from the IDE. I’m at work now, so don’t have time to get into details, but there are many tutorials in the Community for how to do it.
EDIT: Just found the answer in the very next page I checked! See: [OBSOLETE] FAQ: An Overview of Using Custom Code in SmartThings (SmartThings Classic, Groovy Code)

10

Wanted to clarify one thing about the low/med/high values. Its not that Johns values don’t work, they do. Its that atleast on my fan or switch, those values were not the Max it could be at before the fan was actually in/out of that mode. Example, so you can say Low is at 30%, and yup that will work if you send it by the App, and your App will say you are at Low. But if i was to go physically push the button to set to low, and the switch set it to say 32%, which is still Low to the Fan, then your App Reads wrong, it now Reads Medium even though your Fan is actually on Low. This is the problem you might of never noticed, because it depended on if you ever adjusted speed by the Physical Switch, AND it happened to place the % just above what values you hardcoded in thinking was correct. So thats the need to actually test your fan/switch, see what values Actually places your fan into low/med and set the values accordingly, so now the App can set and read the correct state, AND now the physical switch will always report correctly when used in your App. I was looking for accuracy :smiley: That little annoyance was killing me :stuck_out_tongue:

Back on using switch.status on the Primary control is that it will only ever report off/on or atleast revert back to off/on. When i’m out of the main device panel, and looking at all my “THINGS” i like to be able to see what fans are set to without going into the Main Device. If you used status, all you get is Off/On. With the way I made it you get to see OFF/LOW/MED/HIGH from a quick glance :smile:

Also in Johns code, he was using the switch.status to “Set” states like LOW/MED/HIGH, and this would temporarily show up on the Big Button and on the small overview. But the problem is that switch.status will always reset back to either ON or OFF. This was the issue why the app would “forget” or Lose the current speed in that button. So hence the need to track it by another variable.

Hope that makes sense. :smiley:

Hows this for a update to the layout? What you think.

Pasted image314×556 64.3 KB

11

BTW, the double “Fan Controller” label in my screenshot above is a bug in the Android app, nothing attributable to the way it was coded. Ditto for the reverse PRIMARY_CONTROL icon rendering (dark center to light outer), which is reversed from iOS. I actually prefer the i)S rendering, as it gives more flexibility in choice of icons (i.e., visibility). Apparently ST feels the same way, as they show iOS screenshots in the mobile app description on Google Play. :open_mouth:

@ChadCK, the new layout looks fine, as did the old one. That’s the nice thing about ST… we can make it to suite our needs/wants. FYI though, those colored ‘state’ icons do not render in Android (the icon and label do, but not the coloring).

12

They don’t on Android? That’s just horrible, another reason IOS is better? :stuck_out_tongue: I wonder if there is a workaround in code that can be done. I have an old android phone I don’t use any more. I think I’ll fire it up and test it out later. Thanks for the info.

13

Yep. Check my thermostat screenshot posting, comparing the view from my Nexus 5 with my wife’s iPhone 6 (currently the last post in thread):

EDIT: almost forgot about this Android/iOS disparity, later in the thread confirmed and reported by ST staff: Migration to V2 - Hurdles and Best Practices - #264 by dfairbro1

Everything (mostly) works, but we have to be careful about creating platform-centric code.I can only imagine what Windows Phone users are up against. :scream:

14

Nice work @ChadCK, that’s what this community is all about. I tweaked it to use Low/Med/High instead of the % and removed the slider because we’re use to it, especially my wife.

15

@Mr_Lucky

Thank you, this was very helpful and I am now educated on how to do this :smiley:

16

@ChadCK awesome device type. I have four of those switches in my home and never noticed that they weren’t being reported correctly because I mostly use SmartTiles to control everything. I replaced the device type and everything is perfect now.

17

Ok, I’m curious. I’m looking to set up some of these switches here, but I use Alexa to control everything. Would I just set up a virtual switch? I’m guessing four of them, off, low, med, high.

Btw, the app is great… I’ll be installing and using it too.

18

@Stroh Yeah it was an obscure problem, only noticeable if you used the fan buttons. I currently have 5 Fans in the house and going to add 2 more. Since not all of them would always be controlled by the App, I wanted to accurately see what speed they were running at. Since I’m new to SmartThings and Home Automation in general, flipping things off and on with the App and Physical button is something I do regular in testing out new devices as I get them. Thats when I found the problem.

@bamarayne Hopefully someone else can answer that, I don’t have Alexa yet but hopefully in the future. The App does have lowSpeed(), medSpeed(), highSpeed(), off() commands so if you know how to call commands from the device type I would think it would work. But I have not setup Virtual Switches yet, so I have no clue.

19

The fan switch will show up as a dimmer for Alexa to control, so you can turn it on/off directly. If you want the speed control you can tell Alexa to dim the switch directly and choose an appropriate level. Low could be 10. Medium could be 50. High could be 90.

If you went the virtual switch route, you’d need a SmartApp that would call the commands @ChadCK mentioned. A lot more work and possibly name confusion.

20

That makes sense. Alexa well work directly with the switch.

I like to have a redundancy in all of my HA, for the times the automatic part of the hinge isn’t being so automatic.