Jump to content

Should I be looking to transition to Z-wave from Insteon?


ctviggen1

Recommended Posts

Here are five. http://blog.z-wave.com/5-hubs-you-can-use-in-your-zwave

 

There are a dozen more I can think of.

 

Sent from my SM-N950U1 using Tapatalk

One thing to consider is some of these hubs are strictly cloud based. For example, the Samsung SmartThings hub is all cloud based. If your internet goes down so does all your automation, scenes, control, etc. I moved off of X10 and have all ZWave now. Currently working on getting a new ISY running to get away from samsung. Alexa is really starting to piss me off too so I will also be going to an IR solution. Not to mention the possible privacy issues with Alexa.

 

I must say that, so far, I have been somewhat disappointed in the UDI ISY ZWave implementation. I know that the ZWave is fractured as to what some makers will support but, IMHO, UDI needs to get on the ball. Perhaps they want to be married strictly to insteon? As to Insteon, my perception of it is simply that it was X10 v2.0. I had a lot of X10 stuff and I found it way too unreliable. I wasn't about to do any more PLC stuff.

 

Except for the Amazon Alexa shtuff, I have found ZWave to be really reliable with some cool features.

 

In short, considering the ZWave stuff is being made by many companies and the slews of various ZWave controls (more being added daily), and the ability to get some of it at Home Depot :), I would suggest getting away from the proprietary insteon shtuff. With that, all we can hope is that UDI sees which way the wind is blowing and makes a massive push in ZWave development.

 

YMMV

Link to comment

I have 4 fans at my (Miami) home and in each case I carefully carved out a hole in the wall to add a switch, and I separately control fan and fan light.

 

Did you just create an opening or did you install an approved enclosure (e.g., old work box).

Link to comment

Michel,

 

I upgraded to the 11b version but still having issues with the Leviton ZWave switches.  Programs won't respond to switch events or responses (control or status). For example:

 

2set - [iD 000F][Parent 0001]

If
        'ZW 002 Dimmer Switch' is switched On
     Or 'ZW 002 Dimmer Switch' Responding is True
 
Then
        $TestState += 1
        Set 'ZW 003 Fan control(Key1)' On
 
Else
   - No Actions - (To add one, press 'Action')

 

Where:

ZW 002 Dimmer Switch is a Leviton Decora DZ6HD-1BZ

ZW 003 Fan control is a GE Z-Wave Wireless Smart Fan Speed Control, 3-Speed

 

When I flip them around (check for switch on for the fan control) the light comes on.

 

In the device comm events for the dimmer there is this Sun 12/24/2017 20:15:35 : [ZWAVE-RX ZW002_1] [82/01] Hail ACK,AUTO,EXPLORE From=0x02. This is in response to a switch press for on or off - same message. I have yet to find a way for the program to detect or respond to it.

 

From what I have read, this is the prescribed event for Zwave. This tells the controller to query the device. This was from one web source so we know it has to be right. ;)

 

And, just for reference, this is from a query (I think):

Sun 12/24/2017 20:06:42 : [     ZW002_1]       ST 100 (uom=51 prec=0)
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ] ----------------------------------------------
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ] ZW 002 Dimmer Switch
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ] ZW002_1 uid=2 type=4.17.1 mid=29 tid=12801 pid=1
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x5E  V2   ZWAVEPLUS_INFO
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x85  V2   ASSOCIATION
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x59  V1   ASSOCIATION_GROUP_INFO
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x86  V2   VERSION
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x72  V2   MANUFACTURER_SPECIFIC
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x70  V1   CONFIGURATION
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x5A  V1   DEVICE_RESET_LOCALLY
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x73  V1   POWERLEVEL
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x26  V4   SWITCH_MULTILEVEL
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x20  V2   BASIC
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x27  V1   SWITCH_ALL
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x2C  V1   SCENE_ACTUATOR_CONF
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x2B  V1   SCENE_ACTIVATION
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x7A  V2   FIRMWARE_UPDATE_MD
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  xEF  V0   MARK
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]    -  x82  V0   HAIL
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ] - Secure
Sun 12/24/2017 20:08:05 : [ZW-SHOW         ]
Sun 12/24/2017 20:08:06 : [ZW-SHOW         ] Node   2 - ZW 002 Dimmer Switch has the following neighbors
Sun 12/24/2017 20:08:06 : [ZW-SHOW         ]    -          - Node   1 - [This ISY]
Sun 12/24/2017 20:08:06 : [ZW-SHOW         ]    - Repeater - Node   3 - ZW 003 Multilevel Switch
Sun 12/24/2017 20:08:06 : [ZW-SHOW         ]
Sun 12/24/2017 20:08:06 : [ZW-SHOW         ] Node   2 - ZW 002 Dimmer Switch has 1 association group
Sun 12/24/2017 20:08:06 : [ZW-SHOW         ]    Associations for group 001 of ZW002_1 ZW 002 Dimmer Switch
Sun 12/24/2017 20:08:06 : [ZW-SHOW         ]    Max Associations = 5
Sun 12/24/2017 20:08:06 : [ZW-SHOW         ]       - Node   1 - [This ISY]
Sun 12/24/2017 20:08:06 : [ZW-SHOW         ]
Sun 12/24/2017 20:08:06 : [ZW-SHOW         ] ----------------------------------------------

Link to comment

Did you just create an opening or did you install an approved enclosure (e.g., old work box).

Actually for three fans, I was able to use existing boxes. In one case I cut out the space in the drywall. The wiring was not an issue as the old regular switch controlled both the fan and the light. In other words I used where the existing switch was for the light control and the cut-out space next to it for the fan control.

Link to comment

Actually for three fans, I was able to use existing boxes. In one case I cut out the space in the drywall. The wiring was not an issue as the old regular switch controlled both the fan and the light. In other words I used where the existing switch was for the light control and the cut-out space next to it for the fan control.

 

So the fan control device is not in an enclosure at all. The back of the controller is just in the wall. Is the existing box plastic or metal?

Link to comment

So the fan control device is not in an enclosure at all. The back of the controller is just in the wall. Is the existing box plastic or metal?

It is in a plastic enclosure that I purchased at Home Depot. The existing box is metal but I punched out a hole to pull the wires.

Link to comment

DrLumen,

 

Precisely what features of Z-Wave are lacking in ISY and especially in the 5.0.11B firmware version?

 

With kind regards,

Michel

Michel

 

Im on 5.0.11b and FortezZ MIMO2+ ISY only recognizes sensor 1 and relay 1.  This is a multichannel device so should be seeing sensor 2 and relay 2 as well.

 

Would be fantastic if you could take a look and see what wrong in the alpha code. Have tried including/excluding multiple times, repairing, syncing etc.

Link to comment

DrLumen,

 

We will have to take a look. I am not sure whether or not your switch supports change of state.

 

Mwester,

 

I will have to defer hail functionality to Chris.

 

pjjameso,

 

As I mentioned in my last post, we'll have to buy one and see what's going on. This is a very simple device

 

 

With kind regards,

Michel

 

Yeah, it's that Hail signal that is the issue. I will contact Leviton to see if there is a config change that will send the ST messages instead of hails - like some aeon devices support.  If not, what is the chance Hail could be added to the triggers? Even if Hail wasn't fully supported with a query, i could do a work around in rest (I think) as long as I can get a trigger.

 

Merry Christmas, BTW!

 

--------Edit

I just found Query in the program actions so a rest call would not even be necessary - just a Hail trigger.

Link to comment

Hi DrLumen,

 

Will discuss with the team.

 

Merry Christmas to you as well!

 

With kind regards,

Michel

 

Michel, I just got off the phone with Leviton tech support. The tech said he would get it to engineering for info regarding a flash or config type change to eliminate their Hail. I informed him of issue with Samsung and UDI and that the command was obsoleted 1/2017. They are supposed to call me back. I'm holding my breath so if you don't hear from me again...

 

Any chance of getting Hail added back to the Condition triggers in the next release? Please?

Link to comment

Michel, I just got off the phone with Leviton tech support. The tech said he would get it to engineering for info regarding a flash or config type change to eliminate their Hail. I informed him of issue with Samsung and UDI and that the command was obsoleted 1/2017. They are supposed to call me back. I'm holding my breath so if you don't hear from me again...

 

Any chance of getting Hail added back to the Condition triggers in the next release? Please?

 

I'm not sure we actually want Leviton to "eliminate their Hail" -- it's the only thing possible to trigger on and without it, there's absolutely no hope that we can detect a switch on/off/dim event without polling!  The problem, just to be clear, is that the concept of proactively sending a status update when a person turns the switch on/off is patented.  That patent expired very recently, so the majority of the Z-Wave switches and dimmers out there still do not support a proactive status update message -- instead, many of them send a "Hail" message, which can be used by the controller as a signal that it should poll the switch/dimmer to find out what changed.  If Leviton just turns off "Hail" because it's "obsolete", then we have nothing - nada - zip - zero!

 

 

Regarding the last sentence, again, just to be clear and avoid mistaken assumptions for future readers -- one cannot get Hail added back, because it was never supported by the ISY in the first place. :-(  We need UDI to do what many (if not all) other z-wave hubs do when they get a Hail message (obsolete or not): it should simply poll the device that sent the Hail message.  Should be very easy to do.  And if that's not possible for some odd reason, then a next-best thing would be to expose a Hail message as a trigger (that's undesirable because it would then restrict most existing Z-Wave switches and dimmers to being useful only by programs -- which in the ISY add a 1 to 3 second delay (usually the latter)).

 

Just to provide a data point: Running a Home Assistant software on an old Dell PC, with an Aeon z-wave stick, the total response time from depressing the paddle to turn on my office light to the time my desk lamp turns on is a fraction of a second -- the desk lamp is on before the main light has ramped to full-on.  That's a z-wave paddle switch on the wall sending a Hail message, the Home Assistant software getting that message from the Aeon z-wave stick, polling the switch, running the "automation" (their equivalent of an ISY program), sending a "turn on light" message to the Philips Hue hub, which sends a zigbee message to the bulb in my desk lamp.   Yes, that's a silly long sequence of events, but it was set up that way to test things -- and it works flawlessly andfincredibly fast with some open-source software on a surplus PC...   that's the expectation users have, and if the ISY (IMO) is going to be taken seriously in the Z-Wave HA space, it needs to be in that same ballpark in terms of performance. :-)  High bar, indeed.

Link to comment

mwester,

 

Thanks for the details. It seems that we are doomed one way or another. If it's not Java, then it's mobile apps. If it's not Z-Wave, then it's Zigbee. If it's not Zigbee, then it's hail. If it's not any of them, it's a -fraction of a second with home assistant- setting a high bar, and ad infinitum.

 

As I mentioned, we will discuss with the team. Fortunately, we do not base our decisions on doom and gloom.

 

With kind regards,

Michel

Link to comment

I'm not sure we actually want Leviton to "eliminate their Hail" -- it's the only thing possible to trigger on and without it, there's absolutely no hope that we can detect a switch on/off/dim event without polling!  The problem, just to be clear, is that the concept of proactively sending a status update when a person turns the switch on/off is patented.  That patent expired very recently, so the majority of the Z-Wave switches and dimmers out there still do not support a proactive status update message -- instead, many of them send a "Hail" message, which can be used by the controller as a signal that it should poll the switch/dimmer to find out what changed.  If Leviton just turns off "Hail" because it's "obsolete", then we have nothing - nada - zip - zero!

 

 

Regarding the last sentence, again, just to be clear and avoid mistaken assumptions for future readers -- one cannot get Hail added back, because it was never supported by the ISY in the first place. :-(  We need UDI to do what many (if not all) other z-wave hubs do when they get a Hail message (obsolete or not): it should simply poll the device that sent the Hail message.  Should be very easy to do.  And if that's not possible for some odd reason, then a next-best thing would be to expose a Hail message as a trigger (that's undesirable because it would then restrict most existing Z-Wave switches and dimmers to being useful only by programs -- which in the ISY add a 1 to 3 second delay (usually the latter)).

 

Just to provide a data point: Running a Home Assistant software on an old Dell PC, with an Aeon z-wave stick, the total response time from depressing the paddle to turn on my office light to the time my desk lamp turns on is a fraction of a second -- the desk lamp is on before the main light has ramped to full-on.  That's a z-wave paddle switch on the wall sending a Hail message, the Home Assistant software getting that message from the Aeon z-wave stick, polling the switch, running the "automation" (their equivalent of an ISY program), sending a "turn on light" message to the Philips Hue hub, which sends a zigbee message to the bulb in my desk lamp.   Yes, that's a silly long sequence of events, but it was set up that way to test things -- and it works flawlessly andfincredibly fast with some open-source software on a surplus PC...   that's the expectation users have, and if the ISY (IMO) is going to be taken seriously in the Z-Wave HA space, it needs to be in that same ballpark in terms of performance. :-)  High bar, indeed.

 

Well, this where my attempt at brevity backfired.

 

In asking the leviton tech to remove hail I asked them, and referred to other devices, that it should send a basic status instead of simply a Hail. Or, to allow a config change that could be set for Hail or basic status messages like some of the aeontech devices have. I tried to impress on him that they are already having issues and it will only get worse. I reminded him that even Samsung doesn't support their switches completely as it relies on a 3rd party device handler.

 

Surely they just wouldn't remove hail without some other notification. But seriously, I highly doubt leviton will do anything. That was likely just to get me off the phone - they had already hung up on me once before then.

 

As to UDI and Hail, I was thinking Michel said they supported it at one time but removed it since it was a deprecated command class (paraphrased). Maybe I misunderstood but that is why I asked to have it put back in. I agree too that it doesn't seem like it would be a big programming change to add a hex code into the codes being recognized. Like I say, i will be glad for the trigger and can then issue my own queries but it would be best if UDI would do the query automatically at the time of the Hail.

 

On a bit of a darker note, there might be grounds for a class action lawsuit against Leviton (and any others still using Hail) since they are pushing devices out that are supposedly Z-Wave certified but yet using an obsolete command structure. If they don't want to play nice then I don't necessarily have to either.

 

As to response time, whether it be fractions of a second or a second or two, it really doesn't matter to me. I would like it instantaneous but quick is good enough for me.

Link to comment

There's no lawsuit from using a deprecated feature. This is especially true since those devices were out before the feature was dropped. Since the lutron patent ended, it would behoove leviton (and others) to change how their devices work but that does take time and it is still their choice whether or not to embark on that. While smartthings and UDI may not use hail, other controllers do so the products can be used.

 

With all that said, this is my biggest gripe about zwave. It's too fractured. Regardless of what generation, manufacturers still get to pick and choose what they support leading to a confused end user.

Link to comment

There's no lawsuit from using a deprecated feature. This is especially true since those devices were out before the feature was dropped. Since the lutron patent ended, it would behoove leviton (and others) to change how their devices work but that does take time and it is still their choice whether or not to embark on that. While smartthings and UDI may not use hail, other controllers do so the products can be used.

 

With all that said, this is my biggest gripe about zwave. It's too fractured. Regardless of what generation, manufacturers still get to pick and choose what they support leading to a confused end user.

Of course Insteon does not have that issue because it is a monopoly.......  :-)

Link to comment

Insteon is just as "fractured"... 

 

I1 -- and I2 -- and I2CS -- and no good way to determine which protocol is used by which device, and sometimes it even changed with the version of the firmware in the device.  And then there's the RF -- some devices have it, others don't, and again, no good way to know which ones are RF, and which are not other than the advertising glossies (or tearing the device apart).  Some devices support peek and poke commands, others don't - and sometimes the version of the firmware matters when determining if peek and poke work.

 

The difference is that (recent history aside), UDI and the ISY *know* about all the quirks and capabilities and even bugs in each device.  We'll need to develop that for the fractured Z-Wave space, that's all (other controllers are already doing that, so it's something that's possible -- which doesn't seem to be the case with recent Insteon devices, alas.)

Link to comment

Insteon is just as "fractured"...

 

I1 -- and I2 -- and I2CS -- and no good way to determine which protocol is used by which device, and sometimes it even changed with the version of the firmware in the device. And then there's the RF -- some devices have it, others don't, and again, no good way to know which ones are RF, and which are not other than the advertising glossies (or tearing the device apart). Some devices support peek and poke commands, others don't - and sometimes the version of the firmware matters when determining if peek and poke work.

 

The difference is that (recent history aside), UDI and the ISY *know* about all the quirks and capabilities and even bugs in each device. We'll need to develop that for the fractured Z-Wave space, that's all (other controllers are already doing that, so it's something that's possible -- which doesn't seem to be the case with recent Insteon devices, alas.)

Your argument is so weak that it really doesn't deserve a response. My Zwave issues arent about new features that's added due to development such as your case of I1 vs I2CS. That goes with any technology. In the end, new devices can still be used with older devices for both protocols. What IS messed up is the fact that devices within any single generation will have different capabilities in how they communicate. Even now, with what this posting is about, the poster has a zwave plus device that he expected to have certain capabilities due to the certification and it doesn't.

 

Your dual band/non dual band is weak as well. Unless you want to include discontinued models the only non dual band devices are battery powered (a person would need to be an idiot to think it was dual band) and the IOLINC. Which states clearly on its product webpage that it is Powerline only. If a person buys without reading then that's on them.

 

Same thing with peek and poke. First off, that's a feature for developers and something the avg user would not care nor know about. The fact that it was removed in I2CS also limits your argument unless you are trying to include discontinued devices in your argument.

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...