MWareman

I started with Aeotec repeaters. They didn’t help. At all... I switched to using Aeotec Sirens as repeaters - and they made my network reliable. I believe the Aeotec Gen 5 repeaters are better though - but you didn’t specify which version you have.

I believe this is generally the case with all zwave (it’s not an ISY thing, but a zwave thing...). The crypto secret exchanged during enrolling is between the controller and device. No other device is aware of it. If you transfer primary - the new primary does not know the key and secure devices need reenrolling. I’m hoping that the key material is backed up with the full backup - so when we change the board and restore the key material is preserved. UDI will confirm (or refute!) I’m sure... It could be that the secret can never leave the chip...

Thanks. In my case, Aeotec devices I included securely are non-functional - and Aeotec devices I included without security are working. This definitely appears to be an issue with secure devices. @Chris and @Michel - the full zwave backup - does it include key information for secure devices? If I had to guess - we are going to have to remove and reenroll secure devices with a change in the board....

Whenever I query anything, I get this: However - I only have 2 battery devices. All other devices shouldn't need waking. The level 3 logs also does not show ISY trying to wake the device. After the 'Query device when awake' there is simply a failure to communicate message: Querying device 22 (an Aeotec Multisensor 6 - powered by USB, securely joined to the network): Again - crypto failures - and a rogue 'query device when awake' with no attempt to wake device...

I'm also getting this after a query of a lock finally fails: I cannot see anything in the error or operational log that corresponds to it though..

Seems I'm also having issues with my encrypted devices (locks) - Kwickset in my case. During the synchronize - plenty of 'enc=Fail' messages on the lock. Then an 'enc=Ok' at the end of synchronizing the lock. However - a 'Query' fails with 'enc=Fail'. Synchronize: And here is a query of the lock:

Well - that was too quick. Tried a different power supply - and it came right up. Replacement cancelled. Now to try the zwave upgrade again...

All indications are my ISY is dead. It is 6 years old - not too bad... I’ve ordered a replacement.

Yes. That’s where the old board was, and where I put the new one.

Well - seems I've had an issue. Not specific to the z-wave card though. I backed up the zwave card, backed up the ISY, I disabled refresh and replaced the zwave card (making sure I had the correct orientation). Upon powering the ISY..... nothing. Well - blue power light. Nothing else. No LED on the switch port indicating a network link. No LED on the network port on ISY. Not PINGING (I'm using a static IP). Nothing coming up on the serial console (via the USB port). I check the micro-SD card was inserted correctly. Still nothing... I guess my ISY died... just at the wrong moment... Michel - I'll email you to see what other ideas I may try... Michael.

Have you done a heal yet?

When you access via a browser, what URL do you use? Have you tried deleting the desktop icon and recreating it using start.jnlp? https://wiki.universal-devices.com/index.php?title=Main_Page#Installing_the_Admin_Console_Icon_on_Your_Desktop

Wrong way around. Portal includes the network module, for the term of the Portal license. I believe that If you previously purchased the network module (before Portal launched), UDI offered a free initial term to Portal as an option (converting the network module from a permanent purchase to being tied to the portal subscription). If you took advantage of that it may have looked like the network module included portal... at least for the first two years...

Just want to make sure - you are linking within the ISY admin console - and not by manipulating the switches button directly, right? The manual that comes with the switches should be ignored when it comes to linking...

You can. It’s required, otherwise it won’t work. This is how I have my Google account setup, and I use a Yubikey for 2FA. And yes, in my case I have it set to require it each time. Edit. Apparently things changed. However - an app specific password should now work regardless (didn’t used to be that way)... https://myaccount.google.com/lesssecureapps?pli=1

I know at all new point it was intended for 5.0 that one PRO ISY can be a node server to a second PRO ISY - merging the devices together into one tree. I don’t think the functionality is there yet in 5.x - or even if it’s still planned for the release.

I put one under the front of my dishwasher. It saved my wooden floor the other day when a grape stem got caught in the door seal and caused a leak.... the sensor worked perfectly and we were able to clean it up before any damage occurred.

In your Google account settings, setup a ‘application specific password’ for the ISY to use, along with your email address. Using your regular password will not work as the ISY cannot answer the 2FA challenge. You also have to turn on the ‘allow less secure applications’ setting. Scary sounding - but unless you turn that on only applications implementing oAuth can authenticate. sMTP authentication is not possible unless you enable this.

Thank you!

5.0.12 - it seems I mistyped. I was wondering if the issue was resolved with this device before I ordered one. Thanks! Michael.

Sorry to bring this thread up again, but the Mimo2+ is the perfect device for my sump monitoring solution...... Has anyone got this to work on 5.0.10? Chris, if not will the next drop of 5.x properly support this device? I need two inputs, and don’t want to use two devices. One to take the output of a current sensor and the other an analog voltage driven from a liquid level sensor... (the design is to not affect the autonomy of the existing sump system - if any monitoring device fails it simply cannot affect the regular operation of the sump pump....) Thanks! Michael.

I feel that having an admin option to specify an IP address and port then having the ISY send log event to that as UDP datagrams, xml or JSON formatted would be a huge benefit, without much performance overhead (or, frankly, much code needed..). We’d be able to use any number of systems to store or display the logs, much like many of us are doing with the Weatherflow system..

I have the Smarthome one - and it’s worked pretty well. The only issue is there is no ‘positive feedback’ as to the status of the valve. I have it hooked to my Elk rather than an iolinc as the last thing I want is an all-on or all-off event to open or close the valve.

One of these days I’ll learn Angular/JS. It would be a *perfect* framework to write an HTML5 admin console replacement with.

Thre are no websocket client libraries that allow authentication to be added. It’s not an ISY limitation - but a JavaScript/websocket limitation. The only ‘solution’ is to host the html on the same hostname that the websocket connection will be made to - and rely on the browser passing a cached credential when connecting the websocket after prompting the user for authentication in the main browser session. If not hosting the html on ISY, then a reverse proxy is needed to cause the browser to see both under the same host name.