Z-Wave Smart Fan Control Custom Device Type

[ChadCK]

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.

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.

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!

[Mr_Lucky]

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):

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.

[hscox030]

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

[dsclarke]

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

[ChadCK]

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 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.

[Mr_Lucky]

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.

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: FAQ: An Overview of Using Custom Code in SmartThings

[ChadCK]

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 That little annoyance was killing me

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

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.

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

[Mr_Lucky]

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.

@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).

[ChadCK]

They don’t on Android? That’s just horrible, another reason IOS is better? 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.

[Mr_Lucky]

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):

Not at this time. User permissions are the same as they were before. There is the new contact book feature that will allow you to send notifications to a select set of recipients, but if they can log into the app, they can see and do everything.

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

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.

[johnconstantelo]

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.

[dsclarke]

@Mr_Lucky

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

[Stroh]

@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.

[bamarayne]

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.

[ChadCK]

@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.

[Sticks18]

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.

[bamarayne]

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.

[ChadCK]

I’ve updated the code, and recommend everybody who is using the custom device type to do the same.

Fixed the issue reported that on Android the tile is not highlighted. I found through the documentation that the background color only works if the decoration is not “FLAT”. So ha, it was actually a bug of the IOS to still display the background color in “FLAT” mode. I think that should be one of the UI fixes they bring, you should be able to set background color regardless if using decoration flat or not.

Fixed a bug I noticed that if I manually set the speed to 8% it would say I was running High Speed. Well that turned out to be a integer/string comparison mistake. That’s been fixed, showing correct speed now.

Added additional Tile Highlighting now when you select a Tile, it will turn to the adjusting color and show you what you pushed before it becomes active. Its a nice touch you will notice when you use the device now.

I also cleaned up code, and decided atleast for now to move the logic of low/med/high thresholds into the setLevel command. The low/med/high commands now just simply call on setLevel with either “low”, “med”, “high”. It was in my attempt to get rid of the low/med/high commands all together that lead to it, and although i did not accomplish that yet, or maybe it can not even be done, i like the code cleaned up better this way code wise so its staying like so for now.

I’ve been running it this way for the past week and some and I haven’t had any issues come up yet. I just had not had time to come on here to update the github and thread

One minor thing still on my list is to figure out what icon and why it chooses that icon to display on the “Recently” Page, mainly why in the world just the “low” setting is highlighted there and not the other 2 speeds.

And just to Note here, I bought 5 more of the GE fan controls all hooked to different fans and the threshold values were the same for all of them. I think its still good to leave the values as user inputs as its possible other models of the fan controls will have different values, i think John had JE’s and mine we GE’s, must of been a slight change in there make. The good thing is the values are not a requirement to use the device type as it will default to the ones I’ve put in if user does not put it in themselves.

None the less, i recommend updating the custom code on your hubs people

[Sticks18]

One minor thing still on my list is to figure out what icon and why it chooses that icon to display on the “Recently” Page, mainly why in the world just the “low” setting is highlighted there and not the other 2 speeds.

I think it’s because the background color for “low” is the default ST color for a switch that is “On”; so it’s treating that state differently. I don’t think we have any control over that.

[ChadCK]

But its the same setup/color for “med”, and “high” yet those do not get color highlighted in the feed.