Sending Configuration Parameters


#1

Hello

I am a newcomer to Smartthings, after migrating my small (but expanding) Z-wave setup from Vera. I have a number of Fibaro Dimmer Switches (211, I have found the code for 212 in the community) and some TKB Home plug in dimmers and switches. I have all these devices working within Smartthings, however there are some configuration parameters that I had set within Vera to change the behaviours of these devices, which I have now lost.

I am looking to change a few of the basic Z-wave config parameters within the device definitions - I have tried amending the code based on searches in the community - but so far I am reaching a dead end. I have tried adding configuration tiles to devices, but the commands don’t seem to be triggering. And the updated device definitions don’t seem to report the on/off state back to the hub.

Any advice anyone can offer me on where I need to start?

Thanks.


(Michael K) #2

this is a good place to look as a start- it’s for fiddling with parameters on ge dimmers but you should be able to use the code bits to send the parameters you need to a different brand


(rwcrowe) #3

@MichaelK @desertblade @pajaroblanco @johnconstantelo

Is there an app or any code to query a device and return what all of its parameters and information (model/firmware/etc) are ?


#4

There may be some type of professional installer software on the market, but I have no idea. ST must have something that does because it’s available for things like OTA updates.

I usually find what I need for parameters from the manufacturer’s support site, or places like these:

http://products.z-wavealliance.org/regions/2/categories (Configuration Capabilities section gives detail)

http://www.zigbee.org/zigbee-products-2/ (view the compliance document for detail)


(Michael K) #5

I wish there was a generic smart app that you could run against an installed device and pull all its parameters then edit and send back the changed configuration.

Vera has that ability for any device and has had it for many years but I’ve never found anything on smarthings beyond the injection bits I linked to above.


(Michael K) #6

also, another code bit that is a start is the device handier for “homeseer multisensor”- if you grab that code example in the IDE- my device handlers - +create new device handler - from template- select homeseer multisensor from the left column.

that DTH (appears that it) queries the device for 7 z-wave parameters and displays them when you press the settings gear on the device in the smart app. You can edit and then when the device gets configured next it sets the new values (at least for the labeled report value). I am unaware how to force a configure - some devices have a tile button to do that (this example does not). With this device if i hit its configure button it “wakes” up and gets reconfigured. Not sure if smarthings just automatically pushes configuration changes at any time.

Sadly smarthphone app doesn’t tell you anyplace what value is which except the first one is labeled “multisensor report (minutes)”

sorry i have no idea what i’m looking at in the code so i can’t aim you more than that. Hopefully you’re able to read the template and follow?

I am always amazed how little this community has discovered zwave parameters. I had vera for years. Everyone in that community was well aware of the device tweaks you could make and how to read the data and set it. While this community is way more active and makes way more incredible stuff seems that line of inquiry never took hold. People here have lots of requests that i KNOW from experience can be tweaked with parameters but i’m a coding dummy so no idea how to help them except my one minor foray into fiddling with someone elses code to tweak ge ramprates…


(Michael K) #7

and more info from Duncan how to do it with a device handler:


#8

That DH is really no different than any of the others. It doesn’t query the device for parameters. If you look at that DH you’ll see the Preference section (you see that when you tap on the gear) where a user can provide a value, and that value is used in the configure section (when the device wakes up because it’s battery powered).

Actually this community knows a lot about that, I beg to differ.

I can’t speak too much about Vera, but you’d think someone somewhere has to create a “device handler” (or what ever it’s called) for Vera, and that would require the same research into the device and what the manufacturer has designed it to do with the parameters. Experts on Vera need to chime in here.

In your post above, the raw code can be tweaked, or in the example below it can be incorporated into Preferences for a device (again, the gear) to access and change.

Look down at line 125:

In the mobile app for that device (after tapping on the gear), you would see the image below (similar to what Vera does I imagine). Once changed, those parameters get sent to the device either by tapping the Configure tile, or automatically depending on what the developer designed it to do. In the example above, look at line 414.

SmartThings, when it first came out and to this point in time, has kept it’s default device handlers very basic, and did not incorporate configurable parameters into the code, unless it was needed. In those cases it was hard coded and not exposed through Preferences. I have no idea why, but at least the platform enables developers to change them through methods described above.


(Michael K) #9

thanks for explaing more- as above i’m a coding moron.

I think you explain my thoughts better than me here :wink:

it’s not that people dont tweak things- but it’s way more “hidden” and not as common knowledge. As an example, i was looking into why my HSM100 wasn’t working reading all the threads on it- there are a couple where people were complaining about how the device “only report motion” and not no motion. My recollection from my (dark days) on vera that the device reports motion and then after a configurable time period of no motion that it will report that. If the device had a clear configuration that would be more simple to people and they would get it.

on the vera platform every device had a tab where you could enter parameter numbers then a query button to get what they currently are on the device. On the same tab you could also set any parameter and tell it to configure. it’s wide out in the open on each and every device. Leads to lots of discussion (hey does any one know what parameter 1 is?) and solutions.

This community and the developers rock. I love the smarthingd hub. “coding” is even simple enough that a moron like me can dig in and copy or tweak others code (although honestly i can hardly follow if at all). But in this one small way vera had an edge.

PS- while i was reading last night i stumbled on what i though was a post for someone’s smart app to read and edit zwave paramters on a particular device. Again not a coder so can’t follow- but at least i thought someone had a way to do with smartapps?[quote=“johnconstantelo, post:8, topic:34570”]
In the mobile app for that device (after tapping on the gear), you would see the image below (similar to what Vera does I imagine). Once changed, those parameters get sent to the device either by tapping the Configure tile, or automatically depending on what the developer designed it to do. In the example above, look at line 414.

PPS
Screenshot_20170109-205325.png1440x2560 236 KB
[/quote]

here’s the tab that every device on a vera has so you can read the current parameter values and write back changes. No need to tweak each and every handler. it’s just there on every device. There setup is a different paradigm- mostly worse but in this case better i think. you just google for the manufacturers tweaks and then plug and chug a value or two and you are done. No need to edit a DTH or anything like that. Easy peasy for a coding moring. :slight_smile:


#10

LOL, no you’re not!

I think what you may have come across what a SmartApp that lists a device’s capabilities. I remember seeing something like that a while ago.


#11

Yeah, that’s what I was thinking about for Vera. ST is similar if the Preference are set up by the developer to do that. The one thing that Vera does that ST doesn’t for zwave devices is to allow associations between devices. In the SmartThings world, that’s where a SmartApp comes in. ST, via an app, allows for associations across all kinda of devices (zwave, zigbee, LAN, etc).


(Michael K) #12

it’s really weird to me that not only does smrthings “hide” the paramters but they also hide (and posibly dont even really support?) associations.

Big difference between “real” zwave associations and smarthings is while smartthings are flexible as hell (you can control a zigbee from a zwave) that requires the cloud (or at least the hub if we are lucky enough that it’s native devices with the native app). With rule machine and Core that makes smarthings amazing devices.

But with real zwave associations never mind the cloud you dont even need a HUB!. The devices talk to themselves. AS an example you could use associations with the above mentioned HSM100 so that when the HSM 100 senses motion IT all by itself sends the on command to a light or two. Then after the configured no motion delay it sends the off command to the light (thats why it doesn’t send motion and no motion commands all the time like other devices becasue it is able to control motion lighting all by itself- it doesn’t want to shut the light becasue you stood still for 30 seconds). With switches that suppport associations you could use one switch all by itself to send on/off to it’s local load, or with a double tab to a second fixture, or a triple tap to a thrid fixture. And in one slick move- vera hacked around the patent for instant status- by “associating” their hub to every device that supports it- so rather than wait on a poll to get device status and have smarthings react anytime a device changes it would instantly send a “command” to the hub, vera ignored the fact it was command and just used it as a status. So you didn’t have to buy the patented switches to get instant statis

real zwave associations can avoid all delays when the devices support them


#13

Not true. They don’t hide the parameters because, well, they don’t know what those parameters are for all the hundreds of devices that are out there that can work on their platform.

Think about that for a moment. How would you propose SmartThings know about hundreds of devices and the parameters each one could have?

When it comes to associations, you can still do that with your devices, but you won’t get status messages from those devices very quick because they’re not communicating through the hub (local or cloud based devices), and therefore SmartApps (Core comes to mind…) that depend on the right messages/status to execute won’t work as you expect Associations have a purpose, but in a SmartThings world you replace the functions associations did with a smartapp. There’s a discussion in the community about associations if you want to know more about this.

As it relates to speed, when I tap on a switch to turn it on it’s immediate. When I physically use a switch, it’s updated in the app immediately. In the early days of ST, there were delays, but things have changed a lot since then. Instant on for me is about as instant as instant can get with no delays.


(Michael K) #14

With the smarthtings paradigm they DO HAVE to know every device and EVERY device needs its own DTH in order to properly configure it. The “other” way the system is generic and it’s up to the user to google for the parameter info and then use the generic input tab to adjust as they need. The only reason you need to know every parameter of every device is if you are going to go through the exercise of labeling all the parameters- but check the HSM100 (homeseer multisensor) official DTH- the configuration page on the phone app has a handful of values but they only bothered to label one. The rest of the page is generic and i can randomly type whatever value in I want and hope- unlike the “other” system they dont even label the parameter number on the page.

For example- with the “OTHER” system you can have ONE single z-wave dimmer switch “device handler” and that same switch handler gets used for GE switches, cooper, evolve, homeseer, act, leviton, linear, etc, etc. If you want to adjust the ramp rate, the led status, the number of steps, the starting dimmer value, up/down, all on all off response, or anything else any particular switch allows in a parameter setting you google for the parameter number and value you want and then go to the generic parameter entry tab and enter the value you want for the required parameter number. Done. 30 seconds to google, 30 seconds to enter the value on the generic input thing and then done.

With smartthigns 30 seconds to google, take however long to write a specific DTH (likely on a big screen) or find one in the community, use a big screen to get to the IDE (or fight it on your phone) and change the handler, now return to the phone app to make the change.

Using GE ramp rate smartthigns example above, the DTH floating around adjusts the ramp rate (I forget but i think you have to manually go in the IDE to change the values in the DTH code - dont think there’s a page on the app to do it- but not certain.) Even then there are parameters missing. So if you want to edit other parameters you have to create a new DTH or edit that one. The dev that wrote it, god bless them for taking the time to write it and then thanmks even more that they were kind enough to share it, was only interested in editing one thing so that’s the parameters they included in their DTH

I’m not sure it’s as a positive to force every dimmer switch (appliance module, motion sensor, etc) to have it’s on DTH if you want to edit a parameter (and it’s particularly damaging when you can only run the “official” one locally.)

interesting you can do z-wave associations- but it’s “hidden enough” that after using the hub and this community for a year + I’ve not stumbled onto any code to do that (but as above I’m a numb nut coder- lol). I’ll have to go search and look- but honestly I assume i have to wait for someone else to write a DTH for me to do it as I’m just not able to code?

with delays- either there is a delay for smarthings hub to get status after a change or their isnt. So if there’s a delay for status when a directly associated device changes then you are going to have the same delay when the hub does it between when the trigger device has to update status with the hub and then the hub tells the associated device to do it’s thing. If you are saying that’s instant then the hub should have instant status for a directly associated device to change. I’ve had the V2 hub about 15 or so months- my bedroom light switch directly controls my lamp and through the smart lighting app controls a walllwart on my wises lamp (both devices with teh stock DTH so all local as shown in IDE). The delay has varied over time. At worse when there are the meltdowns it can be a few seconds, at best they ramp identically. Most frequently and currently for some time there is a noticeable lag- not a full second by any means but it’s very clear that my wifes lamp lags, it it does vary over time.

As above- I’m a huge smarthings fan. I recommend it all the time. I love it. It is way better than vera and homeseer for ME. But there’s a few tweaks i would make based on m y experience with other hubs- doesn’t mean i dont still love smarthigns. . If i understand at all (and maybe i dont…) I suspect (okay DREAM- lol) someone someday can write a generic DTH/smartapp combo and you could assign the DTH to any device so you could read back the existing parameter values off the device and then edit any parameter on any device as you want. Then change back to the “correct DTH” and be on your way. rules and core show building a broad based generic offering from some genius coders can quickly fix some giant holes in the platform. Just my humble opinion that a generic ability to edit paramters would have value- maybe i’m alone.


(codersaur) #15

Done!

Works for association groups, endpoints, parameters, protection mode, and switch_all mode…