GE/JASCO Dimming problems

Other Devices & Integrations Lighting & Load Control
#41

oTi@ - we are on the same page. JASCO support so far:

ME -

I have bought 2 JASCO/GE dimmers.

One is running version: 6,3,40,3,29
The other is version: 6,3,40,3,33

When the version 3.29 is issues a zwave command it does not ramp up the dimmer, it goes straight to the desired light level. When the version 3.33 is issues a zwave command it ramps up normally. Both ramp up when using the physical rocker switch.

Is there a way to update the firmware? If not can I exchange my 3.29 for a 3.33? I am part of a zwave forum and confirmed with multiple people the 3.29 firmware ignore ramp up when issues a light level using zwave command.

JASCO -

Hello

Thank you for contacting Jasco Products Company.

What type and who manufactured the Z-wave controller that you are using? Just out of curiosity what is the name of the Z-wave forum that you are a part of where other people are have the same issue?

ME -

Hi,

So the 3.29 switch is branded as GE.
The 3.33 switch is branded as JASCO.

As I understand it, all of that is your product.

The zwave controller I am using is called Vera, and their forums. Based on what I read in the forums the older switches worked fine, and the newer. http://forum.micasaverde.com/index.php/topic,13394.0.html starting at post 13.

ME -

Oh sorry to send so many emails.
I changed the senddata command to target the jasco branded 3.33 version with the same exact data and it DOES ramp up properly to 80%.

I think since all I am doing is sending a generic zwave command outside of any interface the controller is out of it. The same command works on the 3.33 version but not 3.29 version.

Unless there is a different command to use on 3.29 to get the switch to do the ramp up/down.

furthermore when I send a direct z wave command to the device:

luup.call_action(‘urn:micasaverde-com:serviceId:ZWaveNetwork1’,‘SendData’,{Node=‘5’,Data=‘0x26 0x1 0x50’},1)

it ignores all of the ramp up rates. the 0x50 is 80% light. The 3rd parameter seems to be the light level. When I issue it, it goes directly to it without ramping.

JASCO -

We have no control over what command the Vera controller is sending. It should be the same command since it Z-wave regardless of the version.

ME -

Hi,

Yes I understand it. Vera does let me type manual zwave commands.
THis command:
luup.call_action(‘urn:micasaverde-com:serviceId:ZWaveNetwork1’,‘SendData’,{Node=‘6’,Data=‘0x26 0x1 0x50’},1)

Is sending your switch, node 6, the data “38 1 80”.
The 80 appears to be the level of light.
The 38 appears to reference the command class: COMMAND_CLASS_SWITCH_MULTILEVEL

I have the ability to send raw z wave data to the switches. So lets take the Vera out of it.
What are the commands in z wave that I can send to see if the 2 switches act differently or the same.

Its pretty damning right now that the same command I issued above works on the 3.33 version of your switch but not 3.29…

JASCO -

Unfortunately sending me command strings doesn?t do any good since we are not trained on the Vera system. I can tell you again that we do not have this issue with any other type of hub. We build the switches but do not write the firmware. Here are technical support we can help you with the install of switches and advised what needs to be done if a switch needs to be deleted from the network and added, we cannot walk you through doing that because again we don?t make the Vera controllers so we don?t have any information on them. If you take the Vera controller out of the equation how are you sending the raw Z-wave commands? We have no idea what the commands are to send to the dimmers.

ME -

I understand this.

How about you send me the raw data I need to send to your switches. While you dont control the commands any controller sends you write firmware on the switches which accept certain commands to do certain things. So you must have a command set to RESPOND to that say dims the light up, or down, or off, or on, or poll the status.

JASCO -

As previously stated we build the switches but do not write the firmware. There are no Z-wave commands that I can give you.

ME -

Who builds the firmware? If your product is a switch with z wave I would think support is all inclusive.

#42

Just out of curiosity, do you have configuration parameters 7 and 8 set on your “device options” tab for the dimmer? These are used to set the dim rate and dim step on some GE/Jasco dimmers. Has somebody mentioned this yet? I don’t recall seeing it in the thread. Those GE/Jasco’s have another pair (9 and 10) that set the rate for the switch paddle, so you can get very different ramp rates with Z-wave commands vs manual operation.

If not, try setting 7 (1 byte dec) to 1, and 8 (1 byte dec) to 3, then save and reconfigure the device. Then switch on via Z-wave and see if you get a ramp. If it works, then it may just be that a version of firmware (3.29 apparently) got out with different defaults for those parameters.

#43

[quote=“rigpapa, post:42, topic:174069”]Just out of curiosity, do you have configuration parameters 7 and 8 set on your “device options” tab for the dimmer? These are used to set the dim rate and dim step on some GE/Jasco dimmers. Has somebody mentioned this yet? I don’t recall seeing it in the thread. Those GE/Jasco’s have another pair (9 and 10) that set the rate for the switch paddle, so you can get very different ramp rates with Z-wave commands vs manual operation.

If not, try setting 7 (1 byte dec) to 1, and 8 (1 byte dec) to 3, then save and reconfigure the device. Then switch on via Z-wave and see if you get a ramp. If it works, then it may just be that a version of firmware (3.29 apparently) got out with different defaults for those parameters.[/quote]

I did have this set but I tried this anyways. So turning on the light ignores the ramp up but turning off the light follows the ramp down. Very bizarre and very annoying that there is such poor support for some of these zwave products. Especially when its different between revisions.

#44

Thanks; interesting read.

I can see how they don’t do the firmware / the support guys don’t know much about Z-Wave specifics. Keep in mind that Z-Wave is a proprietary protocol, so there is a very limited set of folks who have all the details; and they can’t talk about it. (Side note: it wouldn’t surprise me if at MCV this still is one individual.) But I think they should be able to confirm in general terms that you are using a supported command class and that it is not unreasonable to expect the ramp-up parameter to be honored.

If your support guy was in fact clued into the Z-Wave part, he would have recognized that you appear to be doing a generic Z-Wave thing, and it shouldn’t matter whether this is on Vera, or some other controller. (Of course Vera isn’t fully out of the picture, but you’re using her to essentially send raw commands, as you stated.)

Obviously, something has changed in the firmware; again. It’s theoretically possible that they did that to work around an issue with Vera. (Another side note: conversely, Vera firmware works around a bunch of devices’ quirks just to be compatible, even though it’s technically the device that is ‘at fault’.)

Now, the claim is (again) that they don’t have this issue with any other hub.

So:

  • Included a GE dimmer (v3.29) into Vera’s network. Replicated to HomeSeer Zee as secondary. Set the timing parameter to ‘5’, so you can easily spot the difference between ‘instant’ and ‘ramping’.
  • Tried with moving the slider for the dimmer, in both Vera and HomeSeer: same thing!
  • As reported before, it’s instant.
  • Also looked at what is sent (again), and it’s a multi-level set in both cases (so, unsurprisingly, that results in the same dimmer behavior).
  • So same conclusion as before: setting the dimmer to a specific level, other than off, ignores the ramp parameters.
  • Off works, ‘return to previous’ (‘level’ 0xff / 255) works. (The HomeSeer GUI actually has a return-to-previous button on their device widgets in the GUI.)
#45

oTi@ - awesome information.

I missed a call from JASCO support. It essentially said. We dont have any issues with other controllers (you just disproved this). More importantly he said they dont write or have access to the firmware. I have lost the willingness to run it through the chain honestly. If I order anymore ge/jasco products I will ask for firmware before…

It boggles my mind that their support cannot troubleshoot z wave. I mean its a god damn z wave dimmer. It seems they dont have the support structure for it.

#46

So update.
After a long conversation with support I got them to change vera into tricking it to look like my jasco dimmer. Now the only difference is that 3.29 v 3.33 firmware. It still doesn’t dim up correctly. So safe to say it isn’t the vera.

Sucks because the dimmer is otherwise good. Guess it’s time to look at other brands.

#47

I was just going over a topic I started a long time ago and I almost forgot about. My eventual solution to this problem was to use a different dimmer brand (Evolve) and in general avoid the GE/JASCO stuff.

That said, I’m glad that the later version (33) of the firmware seems to have solved the problem.

#48

OK Here is the skinny on this… I spent many years trying to figure out what in the world was going on with these switches… and GE/Jasco is partially correct about the use of the wrong command.

when dealing with COMMAND_CLASS_SWITCH_MULTILEVEL there is more then a single way to tell the light to turn on or off. Go figure…

SWITCH_MULTILEVEL_SET: this command is for setting the level of the switch… 0 being off and 99 being full on and any percent in between. you can also set the switch to level 255 which is to turn on to it’s last on state. this will only work if the switch is in the off state.

SWITCH_MULTILEVEL_START_LEVEL_CHANGE: this command is for telling the switch to dim up or down from it’s current level or from an optionally supplied start level. this will continue to change the light level in it either reaches 1 or 99 or the command SWITCH_MULTILEVEL_STOP_LEVEL_CHANGE is sent to the switch.

The ZWave ramping parameters 7 and 8 lead you to believe they will effect the ramping of the dimmer for all zwave commands issued to the switch… This is not the case. Those parameters will only be used when setting the switch level to either 0 or 255. They also work if you use the SWITCH_MULTILEVEL_START_LEVEL_CHANGE command…

Had MicasaVerde added support for all of the commands in COMMAND_CLASS_SWITCH_MULTILEVEL this issue could be handled either by a user writing a script or internally. This single command would allow for another cool thing. I wil get into that later…

Now this is not that complex a thing to figure out for the GE switches…
so if you want to set the target level to 50 and the current level is at 20. the difference between the 2 is 30

so the % change is 30.

now grab the stored value in parameter 7 which is the step number. this is the number of %'s to change. say that number is 3.

then you do 30 / 3 = 10 steps

OK this is really simple so far yes???

now we take the wait duration between steps from parameter 8.
that is going to be a number between 1 and 255. this number represents the number of milliseconds to wait until the next step occurs you have to multiply the number by 10 to get the milliseconds.

so lets say the stored number is 15…

so 15 X 10 = 150 millliseconds between level changes.

now if you then take that 150 and multiple it by the number of steps you get the totl length of time it is going to take the light to change to the desired level…

so 150 * 10 = 1500 milliseconds…

The reason this is needed is because if you issue the SWITCH_MULTILEVEL_START_LEVEL_CHANGE command with the parameter to make the light brighter. it is going to do this. it will stop once it hits 99 OR it is going to stop if you send the SWITCH_MULTILEVEL_STOP_LEVEL_CHANGE command… That last but is the key…

so now we send the command to start the light getting brighter. we then wait 1500 milliseconds and send the stop command… and guess what you now have… those parameters working correctly when setting the level of the dimmer.

Here is another use for the SWITCH_MULTILEVEL_START_LEVEL_CHANGE command…

make a control that has an up button and a down button. the user presses the up button and releases it when the light is off. the SWITCH_MULTILEVEL_SET will get used instead and the level passed to the switch would be 255. this is also going to work in reverse if the light is on and the off button gets pressed and released the SWITCH_MULTILEVEL_SET gets sent with a level of 0.

But… if you press and hold either the on or off (up or down) however you want to look at it. it is going to send the SWITCH_MULTILEVEL_START_LEVEL_CHANGE command with the direction matching the button you are pressing. this is going to tell the switch to start changing the level… and the switch will continue doing that until you release the button and at that time the stop command gets sent.

This give you an identical type of control to operate the switch as if you were using the switch manually.

OK so here goes with the “candy” if the SWITCH_MULTILEVEL_START_LEVEL_CHANGE was supported then it becomes possible to create scenes that have an adjustable ramping up or down. The user could supply the target level and the length of time they want it to take to get to that level and you can adjust the switch parameters 7 and 8 to make this happen. and then change the level using the method mentioned above…and once the program has finished running then set parameter 7 and 8 back to what they were

There is a version 2 of COMMAND_CLASS_SWITCH_MULTILEVEL. version 2 added a parameter that can be passed to the SWITCH_MULTILEVEL_START_LEVEL_CHANGE command and the SWITCH_MULTILEVEL_SET command… this parameter is the duration of time you want it to take to get to the target level if using SWITCH_MULTILEVEL_SET, if using SWITCH_MULTILEVEL_START_LEVEL_CHANGE the duration would be the time it takes to go from the supplied start level or the current level to either level 1 or level 99

I do not know if the Vera has support for version 2 of the command class. last I knew it did not. this was about a year ago.

If a switch is not a GE Jasco switch and the switch does not offer dimming speed adjustments but it does support level 2 of the command class then you can offer the same types of control.

Here is a use case example for having that ramping speed being dynamic like outlined above and being able to manipulate the speeds by using a scene. Home Theater!!!.. play a move and have the lights dim really slow like in the movie theaters… the manual use fo the switch will operate as normal even if the ramp is taking place. so it is not going to effect manual operation of the switch at all.

Now 5 years ago I had contacted MiCasaVerde asking about the problems with the Jasco switches. and they stated it’s a firmware issue. and in fact it IS NOT a firmware issue. It is a controller software design limitation. GE in later releases of the switches changed the firmware so it would oeprate in a manner that a lot of users were wanting it to operate. YAY GE! But in the end MiCasaVerde blamed the device as the problem because they were to lazy to build a control system that supported the Z-Wave specification in a correct manner.

I am hoping that maybe someone a wee bit higher up in the chain of command reads this… I will guarantee that the “rock solid” Z Wave engine is missing more then just this one command. I am willing to bet a whole bunch of things are missing. This is limiting the functionality that is supposed to be offered to the users. The decision to leave out bits and pieces should have never been made. How do the folks over at MiCasaVerde know what a user will and will not use?? They don’t. That engine is hands down one of the worst Z-Wave protocol bindings made. It is slow, problematic. and requires constant restarting… It even has to restart if a node gets renamed??? what!!! and why does it take so long to start up???.. When I was using the Vera the engine would take well in excess of 2 minutes to start… and I only had 10 nodes…

I do want to thank the Vera tho… Because of my frustration with the thing it sent me out on a mission to learn about Z-Wave to write an engine that supports all of a command classes features… and one that only needs to shutdown when the host device powers down. it never needs to be restarted and not for something as simple as a device name change. Oh and I also want to mention… 13 nodes and it takes approx 900 milliseconds to provide about 98% of the control/available information. and less then 9 seconds for 100%.

I am not a veteran programmer… 3.5 years I have been programming for. about a year ago is when I started to get my feet wet with the Z-Wave Protocol. Now if a single person is able to write a Z-Wave engine that is better in every way and a “team” of developers with 100’s of years of combined experience wrote such a handicapped engine… Fire all of them and Hire me. and pay me what you are paying all of them… I’m Joking… don’t do that… But the engine needs to be completely scrapped NO CODE gets used from it. and write a new one. It took me a single person 6 months… a team of developers should be able to do it in less then 30 days. probably less because the large part of that 6 months was spent learning and the “team” already has a bunch of knowledge.

1 Like
#49

@kdschlosser . Great post on the GE/Jasco details (and your comments on the Vera engine). As all my crappy Evolve/Linear devices are failing I am replacing them with GE mostly now and this is helpful. Where are you using your zwave engine now ?