MWareman

They really should NOT change the specs like that without giving it a new product number....

I wrote most of that wiki article. Unfortunately, iMessage is a closed protocol. It’s not possible to send to it from non-Apple systems. Just like Hangouts on Android and Skype on Windows systems. The wiki page is intended to gather known alternatives so you can pick the solution that works for your application.

I had my Cisco rep contact me on this one, just before it went public... Not sure it’s going to change much, at least initially. Cisco tends to let acquisitions operate fairly independently, at least for a while...

THANK YOU! I truly appreciate it...

After backing up the zwave dongle (to the ISY), perform an ISY backup (to your PC or Mac). The zwave backup is contained within the ISY backup.

Duo would cost UDI to use though. It’s not free for the company implementing it and carries use costs as well (if the SMS or push-to-accept options are allowed to be used). Systems like U2F and HMAC-TOTP (the Google Authenticator protocol) are license-free from a developer perspective and free for the consumer, with no use costs. There is also example code for both that has been well vetted. Another option to consider. Since *most* Portal users will also have either a Google or Amazon account (and both of these offer reasonable 2FA options) - the option *could* be provided to allow authenticating to Portal with one of these accounts (via OpenID Connect). However, for some this would be perceived as worse that a portal without 2FA - so if implemented it should definitely be optional! Personally, I secure my Google account more than anything else - so a Google OpenID Connect integration for authenticating to the Portal would certainly be welcomed by me.

This... It’s my understanding that when you delete a program, it’s marked as deleted (and suppressed from the UI and still operational) but not actually deleted until the save is performed. Also - enhancement request. Can the log record the program ID when program initiated events are logged?

You are, of course, talking about these vulnerabilities (I wouldn’t really characterize it that they were ‘hit’ though) https://threatpost.com/bugs-in-samsung-iot-hub-leave-smart-home-open-to-attack/134454/ Another +1 for 2FA on the Portal. However, rather that doing something vendor locked please implement optional U2F in the logon process... since modern browsers now all support that. Then the user can choose from any U2F compliant solution (which includes YubiKey and many others...)

Auto upgrades are only available to newer production releases. If you are on the latest production firmware version, there is no auto upgrade to newer (beta or alpha) versions and they must be manually applied. Manual is also used if you need to downgrade.

When enabling the Mobilinc portal, you would have clicked thru a warning that it will disable the ISY Portal module - as ISY can only support one portal connection. It’s likely you will have to contact support to have them manually disable Mobilinc to reenable ISY Portal. Many on this forum have suggested that the ‘Internet Access’ option is misnamed. It’s function is to automatically configure port forwarding on your router using upnp. If upnp is disabled on your router (it should be!) then this will always fail.

That was me... The old power supply was lighting LEDs on the ISY and it appeared to be booting, but the network interface would not open up (no LEDs on it or the switch port it was connected to). A strange symptom for sure.

Removing a device from a system does not delete the record of the system from the device (only the record of the device from the system). Performing a remove basically tells the device ‘whatever system you are associated with - forget that’. You can do it from any system, not necessarily the ISY (but it’s pretty easy on the ISY). Until you remove the old system from the device, it will not associate with a new system.

Michel, Do you happen to know that if the Android version on the phone supports it - does the app make use of the OS provided geofencing functionality (https://developer.android.com/training/location/geofencing) - or does it poll for location and implement its own? Michael.

FANTASTIC news! My PRO doorbell, two spotlight cams and floodlight cam are eagerly awaiting integration... Are you able to talk about what will be possible with the integration... Turn on/off light? (Floodlight, spotlight) Trigger program on light changing state? Trigger program on camera motion detect (within defined motion zone)? (Does the API indicate which motion zone was triggered?) Trigger program on bell push? I’d understand if their NDA prevents talking specifics of course....

Momentary to latching is achieved by changing parameters 1 and 2 to ‘0’ (the default is 5)

I included my Mimo 2 - and got the following nodes (this is on 5.0.13A with the 500 series zwave board): The first two appear to be duplicative of ZW 032.2 and ZW 032.4. Selecting ZW 032.3 - I see status 'Off'. Hitting the 'On' button - the status changes to 'On' - and I hear a relay click in the Mimo device. The right-hand output status light lights up. After barely one second - the right LED goes out, the relay clicks again and the status in ISY changes to 'Off'. This repeats with channel ZW 032.4 (except the left output status LED comes on and then off). So - looks to be almost there for outputs (I have not tested the inputs yet). However - the outputs are momentary. I suspect this is a property I need to change though.. Edit: Parameter 1 and 2 sets latching time. Defaulting to 5 (0.5 second) if this is set to 0 it becomes non-momentary. Also to note - parameters are set on the 'WZ 032 Multilevel Sensor' node. The others give a blank error popup for some reason. It would be nice to see UI options for momentary vs non-momentary (and setting the momentary timeout). The parameters are described int he tech ammendix for the device: https://static1.squarespace.com/static/57363221555986b60e62f0f0/t/5919d919ff7c50802f0b93da/1494866202716/Tech+Appendix+MIMO2%2B+8May2017+removed+MI+address.pdf

Perhaps one of the nice features of the 500 series chip - network wide inclusion.

That may be from another command - not sure. I did manually remove some log entries from what I posted because they were for other devices not related to the post - I could have missed this one. I’ve no idea where it came from.

Well - something fixed itself - likely by me stopping messing with it. My locks found routes (Yeah explorer frames!) - and are now reachable, controllable and sending status back to ISY... ZW_027 is an Aeotec Multisensor 5 securely enrolled. It appears to have taken on duty of repeating the connection to my locks. I have to say - the diagnostic info now in the logs is fantastic... All my Multisensors are reporting in, as is my thermostat and the locks. I'll take another look in the morning - but at this point all looks very good. Thank you Michel and all at UDI!

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: