Z-Wave is making a huge change so it doesn’t get left behind in the smart home wars

[LFMc]

I didn't realize zwave (silicon labs radio chip) was single souced.

 

https://www.theverge.com/2019/12/19/21029661/zwave-open-standard-radios-smart-home-multiple-vendors-silicon-labs

 

Sent from my moto x4 using Tapatalk

 

 

[Teken]

On 12/20/2019 at 6:47 AM, LFMc said:

 

I didn't realize zwave (silicon labs radio chip) was single souced.

 

https://www.theverge.com/2019/12/19/21029661/zwave-open-standard-radios-smart-home-multiple-vendors-silicon-labs

 

Sent from my moto x4 using Tapatalk

 

 

 

This is good for everyone from consumer, developers,  to manufactures. Now, if only Insteon had the common sense to do the very same!

[DrLumen]

I wonder what they mean by 'open'. Does that mean it will be free or will they now license the IP to anyone?

I also have to wonder if everything will still need to be certified. While probably another income source, if it is to be open (no certification), then I see a lot of garbage being pushed out that fragments the market by not fully supporting 'the standard'; whatever that currently is.

I do see their development kits are almost cheap now. That is cool. IMS when I first checked, they were like $5k. $379 is now in the experimenters range.

[Teken]

44 minutes ago, DrLumen said:

I wonder what they mean by 'open'. Does that mean it will be free or will they now license the IP to anyone?

I also have to wonder if everything will still need to be certified. While probably another income source, if it is to be open (no certification), then I see a lot of garbage being pushed out that fragments the market by not fully supporting 'the standard'; whatever that currently is.

I do see their development kits are almost cheap now. That is cool. IMS when I first checked, they were like $5k. $379 is now in the experimenters range.

I understood the biggest change is others may make the Z-Wave chip. With respect to being certified I don't believe that is going to change and really that's OK. Meaning you have to set a level of QA. Having said this, I find how they don't enforce that makers need to implement basic to advanced features has been very good for the market.

When I see and read how random nodes appear for devices which literally can't support them - Yet are present?!?!

Come On . . .   

[simplextech]

4 minutes ago, Teken said:

I understood the biggest change is others may make the Z-Wave chip. With respect to being certified I don't believe that is going to change and really that's OK. Meaning you have to set a level of QA. Having said this, I find how they don't enforce that makers need to implement basic to advanced features has been very good for the market.

When I see and read how random nodes appear for devices which literally can't support them - Yet are present?!?!

Come On . . .   

Changes as I understand them.... from releases from the Z-Wave Alliance that are now public.

• Opening of specifications.  This has been "done" before but now they are going to fully open the specification and make it easier for third party integrations and are contributing to the OpenZwave initiative more
• 3rd party chip manufacturing will be increased.  As of today there are only 2 authorized manufacturers of chips.  Increasing this will have a decrease in prices ultimately reducing consumer cost of devices.  I hope and will bring device costs inline with zigbee devices maybe.
• Z-Wave Certification is being revamped and strengthened.  All devices will still be required to go through certification.  Sensors which in the past were not held to high scrutiny are now being revised to provide consistent requirements for core functions of sensors
• All devices must abide by backwards compatibility standards (as always) and must provide support for all Basic command sets.  No changes to the optional features that individual companies may or may not add as these are differentiators and not part of the Z-Wave spec

As to the "odd" random device nodes appearing from z-wave devices.  This is purely a ISY specific phenom as I've never experienced this with ANY other controller and with the same devices.

[Teken]

1 hour ago, simplextech said:

Changes as I understand them.... from releases from the Z-Wave Alliance that are now public.

• Opening of specifications.  This has been "done" before but now they are going to fully open the specification and make it easier for third party integrations and are contributing to the OpenZwave initiative more
• 3rd party chip manufacturing will be increased.  As of today there are only 2 authorized manufacturers of chips.  Increasing this will have a decrease in prices ultimately reducing consumer cost of devices.  I hope and will bring device costs inline with zigbee devices maybe.
• Z-Wave Certification is being revamped and strengthened.  All devices will still be required to go through certification.  Sensors which in the past were not held to high scrutiny are now being revised to provide consistent requirements for core functions of sensors
• All devices must abide by backwards compatibility standards (as always) and must provide support for all Basic command sets.  No changes to the optional features that individual companies may or may not add as these are differentiators and not part of the Z-Wave spec

As to the "odd" random device nodes appearing from z-wave devices.  This is purely a ISY specific phenom as I've never experienced this with ANY other controller and with the same devices.

I recall similar issues were seen in HomeSeer, and Vera. I can't say if this was the case with Smartthings / Other though.

[simplextech]

6 minutes ago, Teken said:

I recall similar issues were seen in HomeSeer, and Vera. I can't say if this was the case with Smartthings / Other though.

I've used SmartThings and Vera and I still have HomeSeer running.  Never experienced the random device inclusion issues like I have with the ISY with either of those.

[DrLumen]

1 hour ago, Teken said:

I understood the biggest change is others may make the Z-Wave chip. With respect to being certified I don't believe that is going to change and really that's OK. Meaning you have to set a level of QA. Having said this, I find how they don't enforce that makers need to implement basic to advanced features has been very good for the market.

When I see and read how random nodes appear for devices which literally can't support them - Yet are present?!?!

Come On . . .   

Yes, they will allow others to make the radio chip but that does not mean those companies will not have to license it from them - like RamBus. If you don't know the story, RamBus attended an open standards conference for a certain set of RAM spec's. DRAM, IMS. All the makers of RAM memory were there and agreed to not patent anything that came from the conference so they would be 'open' standards. The story gets a bit fuzzy but apparently when the conference ended RamBus went out and patented just about everything they could then went full-on IP troll suing companies that infringed those patents. They claimed they had all those technologies on the drawing board before the conference so they were entitled to the royalties.

As to others, I fear there will be some that will [censored]ize it for some reason as a shortcut or to imply a proprietary standard - like Lutron.

Heh, censoredized. I like that!

[Teken]

1 hour ago, DrLumen said:

Yes, they will allow others to make the radio chip but that does not mean those companies will not have to license it from them - like RamBus. If you don't know the story, RamBus attended an open standards conference for a certain set of RAM spec's. DRAM, IMS. All the makers of RAM memory were there and agreed to not patent anything that came from the conference so they would be 'open' standards. The story gets a bit fuzzy but apparently when the conference ended RamBus went out and patented just about everything they could then went full-on IP troll suing companies that infringed those patents. They claimed they had all those technologies on the drawing board before the conference so they were entitled to the royalties.

As to others, I fear there will be some that will [censored]ize it for some reason as a shortcut or to imply a proprietary standard - like Lutron.

I almost broke down in tear reading your reply as it made me relive RamBus. It was marketed as the next generation of super speedy blah blah so built a rig around it. Only for the entire world to drop it like a bad habit!

[DrLumen]

2 hours ago, Teken said:

I almost broke down in tear reading your reply as it made me relive RamBus. It was marketed as the next generation of super speedy blah blah so built a rig around it. Only for the entire world to drop it like a bad habit!

Yep. I luckily sidestepped it but then stepped into a system board part of the capacitor plague. Not good times...

[lilyoyo1]

8 hours ago, Teken said:

This is good for everyone from consumer, developers,  to manufactures. Now, if only Insteon had the common sense to do the very same!

Why? So we can have the same half baked support from each mfg

[Teken]

Why? So we can have the same half baked support from each mfg

Given there has only been three integrators in the past which cover Broan fans, Sky Motion, and Smartinet.

I can’t see how opening up the door for more hardware support and options is a bad thing.


Sent from my iPhone using Tapatalk

[lilyoyo1]

6 minutes ago, Teken said:

 

Given there has only been three integrators in the past which cover Broan fans, Sky Motion, and Smartinet.

I can’t see how opening up the door for more hardware support and options is a bad thing.


Sent from my iPhone using Tapatalk

 

I don't mind more mfgs as long as they don't pick and choose what they support the way zwave does

[larryllix]

Given there has only been three integrators in the past which cover Broan fans, Sky Motion, and Smartinet.

I can’t see how opening up the door for more hardware support and options is a bad thing.


Sent from my iPhone using Tapatalk

IIRC the opening up of the patent is only the radio chip anyway. The data protocol was opened up a few years ago.

Sent using Tapatalk

[asbril]

7 hours ago, simplextech said:

As to the "odd" random device nodes appearing from z-wave devices.  This is purely a ISY specific phenom as I've never experienced this with ANY other controller and with the same devices.

I have a lot of those and these unnecessarily clog up my Administrative Console.

Some are  "extra" nodes to a device such as "binary node, Intrusion Alarm, Tamper Alarm, etc"  that have no information and/or make no sense for the specific device.

If I delete these "extra" nodes, will it also delete the working node(s) of that device ?

Other nodes are from past that won't disappear, even with delete failed node.

Any idea how to make these disappear permanently ?

[Bumbershoot]

41 minutes ago, asbril said:

If I delete these "extra" nodes, will it also delete the working node(s) of that device ?

No.  I delete them when they appear.

42 minutes ago, asbril said:

Any idea how to make these disappear permanently ?

This menu choice should keep them from appearing:

Z-Wave | Options | Freeze ISY Nodes | Yes

[asbril]

30 minutes ago, Bumbershoot said:

No.  I delete them when they appear.

This menu choice should keep them from appearing:

Z-Wave | Options | Freeze ISY Nodes | Yes

I know this, but every time I start the AC, the option sets to No. I am looking for a permanent solution........if it exists 

[simplextech]

1 hour ago, asbril said:

I have a lot of those and these unnecessarily clog up my Administrative Console.

Some are  "extra" nodes to a device such as "binary node, Intrusion Alarm, Tamper Alarm, etc"  that have no information and/or make no sense for the specific device.

If I delete these "extra" nodes, will it also delete the working node(s) of that device ?

Other nodes are from past that won't disappear, even with delete failed node.

Any idea how to make these disappear permanently ?

Those aren't the "extra" nodes I was meaning.  I'm taking an educated leap those are coming from your sensors?  Especially motion sensors.  Those are actually not extra nodes but they are base nodes for the device class.  For whatever reason in the z-wave driver it was chosen to do nothing with those nodes.  They are valid per z-wave specification for that node class but the ISY z-wave driver just doesn't use them.... dunno why.

What I was meaning by strange extra nodes that is unique to the ISY is why would a power plug suddenly have a color switch associated with it?  When you have no color capable devices?  There is ONE switch that has this color switch function the Aeotec plug which has the color bezel.  Otherwise a standard energy meter switch like the ZEN15 does not in any way have a color switch.  I've checked this with the raw device in the Silicon Labs PC controller from the development kit as well.

I've had other odd things attach themselves to my Thermostat as well like a leak sensor??? Huh?  It's just random oddness.  I can delete the devices and sometimes they don't reappear and sometimes they do. 

[Teken]

11 hours ago, lilyoyo1 said:

I don't mind more mfgs as long as they don't pick and choose what they support the way zwave does

Well, I'm unsure what you mean by *Pick and choose* so will let you clarify. What I like to see is first more competition as there has never been any. So one can not simply state *No, lets just keep doing what we're doing* well that doesn't work in terms of driving down the cost or offer more options should one maker fail. With respect to options I'm looking for different hardware like analog I/O, digital keyboards, real energy monitoring, upgradeable firmware, tighter integration with industry known platforms.

Firmware: In 2020 there is no reason firmware can't be done as this has been offered by Z-Wave for years. There are countless industries that have a means and method to flash firmware remotely either through LAN / WAN or direct. Given, everyone can update the programming on a Insteon device Smartlabs needs only allow the same in the EEPROM which holds the firmware. Absolutely no reason why this can't be done over RF / Power Line as the information is so small this is a none issue.

It goes without saying they must use industry best practices of implementing a backup / roll back plan. Everything we do that relates to software / firmware is designed and built around this where the system(s) backup the current firmware. It then completes a mini POST to verify the hardware can support the size and features of the pending update. It then verifies the integrity of the firmware blocks and that it's signed. It then proceeds to hold the existing firmware in high memory begins the install and verifies the firmware has been successfully written and installed.

The system reboots and confirms another POST and verifies key metrics are present and fully operational. If at any point there is a variance the firmware will halt and roll back to the previous version. Detailed verbose logging is present at all times and reports back any issues which relays back to the on site tech / vendors. Depending upon the system the hardware is rebooted no less than two times to insure this isn't what we call *One Time Lucky*.

The tech will need to define the high memory hold so the system can complete the POST and run for those operational tests. 

Hardware: In the last 15 years of watching and having sampled at least 90% of all Insteon hardware. It has always come across to me at least who ever the engineer(s) were they had a great concept but once released never had the opportunity to iterate the initial creation?!? One of the biggest jokes about Insteon has been things come out and on the surface look really nice but once you get into the weeds things are completely different. EDOC's that don't match what the device can or can't do? Features that 100% have never been tested in the field or offer zero insight as to what they do or how to adjust them to work normally. My hopes with a new vendor is that they come into the market first and foremost using industry best practices of the philosophy *Cradle to Grave*.

In our industry this is one of the major tenants of what drives our field as there is very little room to make mistakes. One must have a solid concept and from there they make it into reality by producing a working sample. You continue to test, validate, refine, and iterate, until Alpha / Beta trials. UDI has to be one of the leaders in the Home Automation industry where they offer the public at large the ability to trial new Alpha / Beta firmware that offers more features and kills bugs.

I know many here have grown tired of the waiting for the so called *Official 5.XX*. But, having gone through the 26, 99, 994 2.X, 3.X, 4.X, and now 5.X that so called long wait is simply a slow and steady march toward stability & reliability.

Quote

*Don't strive for perfection - Strive toward progress*  

 

[Techman]

11 hours ago, asbril said:

I have a lot of those and these unnecessarily clog up my Administrative Console.

Some are  "extra" nodes to a device such as "binary node, Intrusion Alarm, Tamper Alarm, etc"  that have no information and/or make no sense for the specific device.

If I delete these "extra" nodes, will it also delete the working node(s) of that device ?

Other nodes are from past that won't disappear, even with delete failed node.

Any idea how to make these disappear permanently ?

Create a new folder in your tree and move the unwanted nodes into the folder. They will still exist but you won't have to look at them.

[asbril]

28 minutes ago, Techman said:

Create a new folder in your tree and move the unwanted nodes into the folder. They will still exist but you won't have to look at them.

That is what I did several years ago, 1 folder "Not used nodes", with empty nodes that come with otherwise working devices, 2 folder "Not operative nodes" with nodes of old devices that I was unable to exclude.

I just would like not having to use these folders. It would give me a cleaner AC. This is not a major issue but it would be nice, in a future upgrade, being able to delete or hide these nodes.

[lilyoyo1]

3 hours ago, Teken said:

Well, I'm unsure what you mean by *Pick and choose* so will let you clarify. What I like to see is first more competition as there has never been any. So one can not simply state *No, lets just keep doing what we're doing* well that doesn't work in terms of driving down the cost or offer more options should one maker fail. With respect to options I'm looking for different hardware like analog I/O, digital keyboards, real energy monitoring, upgradeable firmware, tighter integration with industry known platforms.

Firmware: In 2020 there is no reason firmware can't be done as this has been offered by Z-Wave for years. There are countless industries that have a means and method to flash firmware remotely either through LAN / WAN or direct. Given, everyone can update the programming on a Insteon device Smartlabs needs only allow the same in the EEPROM which holds the firmware. Absolutely no reason why this can't be done over RF / Power Line as the information is so small this is a none issue.

It goes without saying they must use industry best practices of implementing a backup / roll back plan. Everything we do that relates to software / firmware is designed and built around this where the system(s) backup the current firmware. It then completes a mini POST to verify the hardware can support the size and features of the pending update. It then verifies the integrity of the firmware blocks and that it's signed. It then proceeds to hold the existing firmware in high memory begins the install and verifies the firmware has been successfully written and installed.

The system reboots and confirms another POST and verifies key metrics are present and fully operational. If at any point there is a variance the firmware will halt and roll back to the previous version. Detailed verbose logging is present at all times and reports back any issues which relays back to the on site tech / vendors. Depending upon the system the hardware is rebooted no less than two times to insure this isn't what we call *One Time Lucky*.

The tech will need to define the high memory hold so the system can complete the POST and run for those operational tests. 

Hardware: In the last 15 years of watching and having sampled at least 90% of all Insteon hardware. It has always come across to me at least who ever the engineer(s) were they had a great concept but once released never had the opportunity to iterate the initial creation?!? One of the biggest jokes about Insteon has been things come out and on the surface look really nice but once you get into the weeds things are completely different. EDOC's that don't match what the device can or can't do? Features that 100% have never been tested in the field or offer zero insight as to what they do or how to adjust them to work normally. My hopes with a new vendor is that they come into the market first and foremost using industry best practices of the philosophy *Cradle to Grave*.

In our industry this is one of the major tenants of what drives our field as there is very little room to make mistakes. One must have a solid concept and from there they make it into reality by producing a working sample. You continue to test, validate, refine, and iterate, until Alpha / Beta trials. UDI has to be one of the leaders in the Home Automation industry where they offer the public at large the ability to trial new Alpha / Beta firmware that offers more features and kills bugs.

I know many here have grown tired of the waiting for the so called *Official 5.XX*. But, having gone through the 26, 99, 994 2.X, 3.X, 4.X, and now 5.X that so called long wait is simply a slow and steady march toward stability & reliability.

 

What I mean by pick and choose is how each company supports x but not y or z. But some will support yz but not x. There are simply too many caveats with zwave. 

People need to get over lower prices. Devices aren't priced that high and with the multitude of sales, it's not like you're paying much anyway. In the end, you get what you pay for. The only thing that would change is cheaper companies making cheaper products just as you have with zwave. 

More device types I can agree with. No argument there 

Even with zwave having the capability, firmware updates are a rarity. Most companies simply release a new rev to the market. The few that have pushed updates wasn't for new features (for the most part) but for bug fixes in products that never should have shipped that way from the start. In regards to why no updates in 2020....people are idiots. Send something to the masses, someone somewhere will find someway to screw it up and blame someone else. 

I don't mind insteon or whoever adding anything to a switch to make it better. I just don't want them adding stuff for the sake of adding things. The only thing that does is drive up costs unnecessarily and overly complicates things

[Teken]

5 hours ago, lilyoyo1 said:

What I mean by pick and choose is how each company supports x but not y or z. But some will support yz but not x. There are simply too many caveats with zwave. 

People need to get over lower prices. Devices aren't priced that high and with the multitude of sales, it's not like you're paying much anyway. In the end, you get what you pay for. The only thing that would change is cheaper companies making cheaper products just as you have with zwave. 

More device types I can agree with. No argument there 

Even with zwave having the capability, firmware updates are a rarity. Most companies simply release a new rev to the market. The few that have pushed updates wasn't for new features (for the most part) but for bug fixes in products that never should have shipped that way from the start. In regards to why no updates in 2020....people are idiots. Send something to the masses, someone somewhere will find someway to screw it up and blame someone else. 

I don't mind insteon or whoever adding anything to a switch to make it better. I just don't want them adding stuff for the sake of adding things. The only thing that does is drive up costs unnecessarily and overly complicates things

2020 is going to be really boring having to agree with you all the time! 

[lilyoyo1]

44 minutes ago, Teken said:

2020 is going to be really boring having to agree with you all the time! 

Now got see how I felt. Lol