Dimmer module that can be set to ramp up


(Randell Pelak) #1

I have a few of these
https://www.amazon.com/GE-Wireless-Lighting-Appliance-12719/dp/B0013V58HU/ref=pd_lpo_vtph_147_tr_t_3?_encoding=UTF8&psc=1&refRID=FFBYAE6XFBA2Q86QRR9N

When you send the off command they ramp down to off. But when you send an on command it “snaps” on. I would like a device that ramps up when something is turned on… (my old insteon could do it). Does anyone know a device that supports being set to ramp up in response to on signals?


(Randell Pelak) #2

I guess it doesn’t exist. Shame. It was easy with my insteon stuff.


(Robin) #3

Does it need to be an appliance rated module? Or for use with lighting circuits?


(Robin) #4

For lighting, you can adjust the ramp up/down speed and step size with a Fibaro Dimmer 2.


#5

There are several, including the GE that you already have, but two different things are required.

First, you have to set the parameters for the ramp rate appropriately. You may be able to do this just by tapping the little gear icon on the device’s details page. See the following thread for discussion of how to do that:

If that doesn’t expose the correct parameters, you can use the Z wave tweaker device type. You just temporarily assign the device to the tweaker, make the parameter changes, and then assign it back to your everyday device type handler.

And here’s the manufacturer page for the GE models on the various parameters:

http://www.ezzwave.com/advanced-operation/

OK, that’s the first part. Second, your everyday device type handler has to not try to force full on each time. As it happens, about two years ago a lot of people were complaining about the ramp up behavior, and many of the device types were modified to force “snap on,” the opposite of what you would prefer. I’m not sure if that includes the stock DTH or not, but it might.

If that’s happening, it’s not a big deal to change it, but if you do change it then your new device type Handler Will not be able to run locally because no customized code can run locally. That may be a problem or may not, but if you feel that the device is less responsive when you are using the custom handler that would probably be why.

OK, so it can be done, it can be done with many models, and it can be done with the model you already have. :sunglasses: You’ll do a one time parameter configure to get the Settings the way you want, and then you need to make sure the DTH you are using doesn’t try to get around that configuration.

Unfortunately, I am not feeling well today and I can’t walk you through the details of the steps, but I am sure there are many community members who will be glad to help.


(Randell Pelak) #6

Thank JD. That is great. Shame GE support told me it couldn’t be done. :frowning: I should learn not to trust support people. Looks like the option used to be there in device setting, but got removed for some reason. So I will have to install the tweaker.

Overall, is there a guide to the general flow of communications between things? Like I am gathering that the hub talks to the device handler which then talks to the device. I am sure there are more layers. I am a software guy, so I should be able to understand it all. And I am also looking for any guide that helps with understanding the tools for debugging and understanding what is happening.

thanks.


#7

The hub is a CPU with radio antennas.

The DTH is software, a device driver. Most of these run in the cloud, a few of them can run locally on the hub itself. But what happens is when the hub wants to use one of those radio antennas to communicate with a specific device, like the GE module, The request gets run through the DTH so that it will be formatted into the exact string that the end device expects. And the same thing coming back the other way. The end device sends a radio signal to the antenna in the hub, it is received and run through the device type handler to be translated into something that the smartapp software on the hub or in the cloud can understand.

The communications between the hub antenna and the end device are always the same, but different device type handlers may interpret them differently. A good example is that some devices allow for a tap, double tap, or long hold on a switch. The device type handler typically converts those to look like button one, button two, and button three, and then reports those “events” to whatever smartapp has been subscribing to that switch. That way One smart app can process events from many different devices, with many different form factors, because the device type handlers convert the actual events into this common structure. :sunglasses:

You’ve probably already seen the custom code FAQ, but if not, you’ll need it to be able to use the tweaker anyway, so here it is. It covers the main concepts.


#8

Since you have a technical background, you also might be interested in the Welcome FAQ in the Community – created wiki:

http://thingsthataresmart.wiki/index.php?title=Welcome_FAQ


#9

Hey, I was support people! :stuck_out_tongue_winking_eye: (Also a field engineer, though, which I think does make a difference. But in my group we were required to spend one day a quarter on support calls, which was always an interesting experience. That’s a hard job!)

I think it’s more a matter of “trust, but verify.” A lot of things change over time, and sometimes tiny details matter. Never hurts to do a little extra research. :sunglasses:


(Randell Pelak) #10

lol, I was thinking trust but verify too. They used to use that phrase at my old job a lot. but they used it to replace saying, that guy has no idea what he is talking about… :slight_smile:
Anyway, the use custom code part of the faq gave me the internal understanding I needed.
I can work from that on this one. But I think I need to get my overall system working consistently before I try to mess with it deeper. So you may see posts from me on that soon. Just can’t get the hub to talk tot he one light I have at the moment consistently. But I will keep digging a bit more.