simplextech

YMMV however you can add the PC Controller as a secondary to the ISY. Then from PC Controller you will be able to see/control the devices and you can apply the firmware. Now the thing about firmware and z-wave devices..... unless it fixes a problem you're having it's generally better/safer to pass on the firmware update. If it's not broken don't fix it

@tim2u you can look at various Wifi compatible locks. There's a couple out there with potential. I'm currently waiting for Alfred to release their API (in the works) to develop a IP based nodeserver for that lock. In the meantime there's Lockitron oops nevermind. Just searched adn they are now shutdown. Pity had promise.

I agree it would be reasonable. The issue is the enormous variety of fly by night Wifi devices that have flooded the market. Which vendor to choose, how long will they be around. Another issue that comes up from Wifi devices is most consumer Wifi being a router and built in access point have a pretty small device limit before the AP starts dropping connections. The support noise that arises from users complaining just adds to the support cost of having to answer all of those complaints. Wifi is a great option for small installations or for specific use cases but it's difficult in larger scenarios.

In most I agree so we're starting on a good footing right? Wifi is just another medium of communicating with IP devices, but it's been used synonymous as a device interface so I'll continue using it. Yes UDI could, maybe should support one or more not all wifi device vendors. I do not agree with your pick of Wyze because they have been outright hostile about access to their API for development and interfacing and they are purely cloud based which I do not promote if given options. For the same reason I would not consider Tuya based devices even though they are dirt cheap and plentiful they are very closed with their API marketed and branded six ways from Sunday making it error difficult to determine what device and API you are really actually working with and because of this who know's for sure who's server you're really sending data to??? The Tasmota project is awesome and the Sonof devices are really cool and I like there's a NodeServer for them but... not everyone can hack a device and replace the firmware so that's not a broad enough option to most. Now on the flip side if TP-Link would open up through a partnership for an official API integration which could use their local API with option to use the cloud API I think that would be great. The existing NodeServer works very well but it is reverse engineered. The same goes for Etekcity aka Vesync devices which are cheap and work well but again it's a reverse engineered integration. Now I've thought about this a little since your previous post. It's been a while since I've done that so I thought about it and thought... what about "Shelly" devices? They have a lot of EU devices and are expanding their US device line up. They also have a very open API and support direct local integration via multiple integration friendly protocols including HTTP and MQTT. Almost the perfect device for integrating and they are wifi. Hmm..???? So I ordered a couple of the new US Shelly Plugs to play with. Would a Shelly integration scratch the Wifi itch even though such a "official" supported Wifi would be vendor limited? Is there another vendor with quality products and open integration which would be more preferred? Or is the preference still a wild west approach of NodeServers being developed at random based on individuals at the time interest and then some supported and others abandoned as there's no accountability as they are free. This is the primary reason open source projects such as Home Assistant and OpenHAB have hundreds or thousands of integrations some of them are excellent and some of them are FUBAR. This discussion comes up on many forums about drivers, plugins, components whatever that platform calls them and people always point to the number of components available for Home Assistant as evidence of why it's great. Reality. Developers write code for two reasons. Personal interest or Money. Personal interest and use changes over time but paid products tend to survive the long as long as a product sells or has a subscription base then money is gained and development continues. Will an official UDI Integration come from this? I dunno only @Michel Kohanim can weigh in on that. Will a Simplex Technology supported NodeServer come into play here? I haven't decided yet. An official integration takes time to develop and even more time to properly support such a thing. Time is money after all. So there are factors at play to weigh on this. Sorry to everyone for the rant. Just my 2cents worth.

Ok. Which vendor? There's one major problem with wifi devices that neither UDI or any other home automation platform can change. All of the wifi device vendors all are trying to create their own proprietary ecosystem and have closed API's. The closest thing to an open API comes from TP-Link with their Kasa devices. Which has a nodeserver already. So how do you propose Wifi be supported when there's no standard API to develop against?

I noticed in the Z-Wave tab there's a new option menu to enable/disable Network Wide Inclusion/Excusion. Make sure you change that to Yes to use NWI.

Different stick. The $19 stick is the Official reference stick from Silicon Labs and it is a Z-Wave 700 series USB stick. It is cheap (costing) but it is the reference standard by which others must validate against. Oh and yeah I have 2 of those and they work great.

Oh please NOOOOOO.... that stick aka Nortek stick is horrible and oh BTW you can't backup the z-wave portion so.. umm... SOL if the stick fails... it's also NOT a 700 series stick so you'd want to be upgrading in a year or so and without being able to backup and restore... ooops too bad! Would Zigbee end devices be nice with ISY... sure! But... that's a whole different ball game and a new can of worms and up until just recently with Zigbee 3.0 there really wasn't a REAL standard to cling to and call something supported so it was always a hit or miss and MUCH leaning on community developed drivers for most devices.

No it wont cause a "problem". @blueman2 pointed out that the "update neighbors" is still available which will work for some/most mixed environments. I'm currently treading in somewhat of an unknown here as well as I no longer have a mixed environment to test with. However my concern which could be unfounded is that the explorer frames are not being responded to by the non plus devices. This may not cause any problems at all if doing the update neighbors sends that information back to the controller to update the routing table with. So what I'm getting at is... No you shouldn't be alarmed about this. But aware that the "heal" being removed is not some "new to ISY thing" I've seen it with other systems as well. How this will affect things in real world scenarios I can't tell you as I don't have a mixed environment. So far I've not heard from any systems that don't have a "heal" the screams of bloody murder and calling for heads to roll from any users... about this issue.. I think many more pains are involved from those trying to implement S2 security (across the board with all systems) at the moment and I'm curious when that will emerge from the depths to the ISY and how "SmartStart" will even be handled....

Like @lilyoyo1 said... send it back... return it.

Technically by the Z-Wave Plus specification a "Heal" is.... "Not necessary".... Now the details of that is because Z-Wave Plus introduced "Explorer Frames" which when a route to a device no longer works the controller will send out lots of explorer frames that essentially ping the neighbors and ask who their neighbors are and the controller will "self-heal" and rebuild the routing table. This normally actually works ok and the mesh will re-route within seconds. The spec and docs say something like "up to X seconds" if I remember is something like 5-6 seconds for max time to send/respond to explorer frames. In general this does seem to work well in a ALL Z-Wave Plus mesh.... Now the kicker hits if you are running in a mixed Z-Wave environment..... some Plus devices and some NON Plus devices... Non Plus don't understand explorer frames so they don't respond and this can leave a hole in the mesh or inability to communicate with devices that can only route through that one non plus device. Now this is an extreme example of a broken mesh of a single device being the single route to another device... BUT... it can happen and the more non plus devices in your network the higher the chances of this happening..... In a mixed environment like lots of z-wave networks TODAY I think (my opinion) that network heal/optimize should be left in the controller as an option and in my preference I like it when controllers allow doing a per-node optimize so instead of "healing" the whole network one device at a time I can choose the node I want to optimize and force a neighbor update on. Like when I add another node and I just want to ensure the neighbors get the message they have a new neighbor.... knock knock here's some cookies

I'll second this sentiment. Systems should be able to "function" through manual control as well as automations (programs). The programs add spice and "smarts" to the overall system but "things" happen and it defeats the idea of a smart home when a dumb switch doesn't work because the "system is down".

Setup the older Occupancy nodeserver in the portal. Go to Connectivity IFTTT setup to generate a token URL for that purpose Use the phone to send a HTTP GET to that URL associated with that "Geofence" user Setup program to do what you want when that "user" becomes present or away This way your portal credentials are not exposed and the access is limited to a single function of marking the person home/away.

This is simple. Pay someone to write the nodeserver or donate the GEM + CT's necessary to develop against. Easy... maybe... Sexy in the Admin Console? ?

Aren't we all already... except the MIA company part... You send money to SmartHome who's products are made in China... so... same thing. Except if you bought it directly from the manufacturer you'd probably get support. Only good thing I have to say about the MSII is the ability to use the "On-Only" feature and linked to a switch. That's it. Wrap that in program to make logic decisions on when to turn off and call it a day. Nothing else about the MSII worked correctly for me. Glad I got rid of them!

The drivers are there for Linux. I don't know about Mac. However you will still need a software controller to interface with it. If you're intending to do firmware updates then from the Mac you will need to run Parallels or Fusion to run a Windows VM and you can then use the free Silicon Labs PC Controller to flash the firmware. Same would apply from Linux you would need a Windows VM to run the SiLabs PC Controller software to flash firmware.

Not without a VPN or port forwarding (BAD!!!).

Your link is not working but I remember it from before and the info wasn't very "interesting" to begin with nor was this "ordeal" very disgusting... hear say from a anonymous user on a forum... hmm never happens.... sooooooo what's the good stuff or is that it? If so I'm disappointed

But... but.... now we're all waiting for the story....

I don't know for sure but the typical sources are "sold out". With the COVID-19 issues around manufacturing and shipping from China this really isn't a surprise.

This is something I can definitely give props to Inovelli for. They are very open to problem reports and have appeared active with finding the root of the problem and fixing it when it's their problem.

So as to quote other forums. Here's the favorite Hubitat and the Inovelli bulb that is Z-Wave Plus Certified Hub keeps locking up This particular thread is in regards to the Hubitat hub continuously locking up presumed to be caused by the Inovelli RGBW bulb. This bulb may or may not be the problem as the bulb is a certified device and the hub is not a certified gateway. The "driver" in question is the one developed by Inovelli for this bulb so in theory everything should work but there's a user having significant problems not with just one bulb but several on this hub.... who's the blame? In the end when it comes to these DIY forums the fan boys of the system are going to defend their hub of choice no matter if this was a ISY problem or a Hubitat problem the fans are going to blame some device as the cause and wash, rinse, repeat with every "bad" device that someone has issues with on their hub of choice. There's really a flaw in any gateway that uses "drivers" to function and work with a Z-Wave Certified device.

Happy to address both questions around "compliant" and around this one above. First the compliance item is around the Z-Wave Certification itself and the liberties that vendors take in the "optional" portions of the certification. I like to pick on Fibaro as my goto in this category of doing oddball things that are off the cuff but because they "meet the bare minimum" requirements for certification then they get the sticker. I've seen this with other vendors as well. This is why I also point to both ends of the stick and I do device verification with multiple platforms BEFORE I point the blame at the device or the gateway. Often it's a mixture of both where a device has "extra" things that are not part of the Z-Wave Certification specifications or sometimes not even part of the z-wave specification at all but those devices are generally designed to accompany and perform best with their own brand. Often times what I do with devices for ISY are not necessarily verification of "conformity to specification" but using the device and checking settings to provide recommended setup or notes. Such as (Fibaro again) those buttons are a real pain to include in any controller even their controller but it can be done but how they "show up" in the ISY versus another controller will make you scratch your head and wonder "what do I do with this?" Sometimes a dimmer is reporting back on basic report and the ISY is expecting "basic set" and that's just a flag in the options to toggle but if a user doesn't know then that leads to a "bad device" outcome. I post all results, good, bad, ugly to the Github listing (until there's something better) which lists the devices, vendor, info and notes if there's any setup challenges or issues. This github issue list is open to the public so please feel free to add your own testing information and results. Since you now have an ISY on hand for testing it's likely easier and faster for you to test than me.

That user post is a half-truth.... The ISY994i ZW Firmware 4.3.0 is a Z-Wave Certified gateway. https://products.z-wavealliance.org/products/1228?selectedFrequencyId=-1 The ISY994I ZW+ Firmware 5.x is still in BETA and knowing UDI will go through certification when they are ready and can fully pass certification. The other hub mentioned in the post is not Z-Wave or Z-Wave Plus certified at all however Inovelli has done a lot of work with them on custom "drivers" and firmware updates to make the products "work". The other software based system is the only one of the three in discussion that is Z-Wave Plus certified and that is dependent on the version 3 of the software as the new version 4 unless they use the old v3 z-wave plugin will also require going through the certification process again. As long as Inovelli sticks to standards of Z-Wave Plus then in time the ISY will be certified and things should work out of the box no fuss. However until both sides are fully compliant with standards it's all up in the air. At this point in time the ball is in the ISY corner waiting on them to release and certify. I've not received any product from Inovelli to perform any testing/validation with so I can't say for sure where any of the issues originate from. I have been doing testing with Zooz and ISY for a while and there have been issues found that are being addressed.