MWareman

Woot! About time. This should have been the situation from when they first started prompting for devices to be assigned to room.... I can now add a *lot* more spokens!

Right-click the icon, I forget which tab, but find ‘Compatibility mode’ and change it to ‘Windows XP’. The issue is your screen is a HDPI screen, and Java does not play well with newer APIs that HDPI exposes. This seems to work around the issue for most people.

In my case, if I arm the Elk and one of my two zwave locks is unlocked - I send a ‘Lock’ command (rather than prevent to Elk from arming, or issuing a disarm). If the lock gets stuck - I send a high priority Pushover message to let me know. Works well enough for me - though I’d love to add the lock strike switch at some point...

All true, but question was asking about preventing the Elk from being able to arm (which requires a native Elk zone) vs having the ISY see an arm event and reverse it if the lock is unlocked. Same effect for sure (security wise) but I’d be concerned someone might arm the system and walk away, thinking they had armed it only to find out later their arm request was reversed because the lock was open. Notifications go some way to address this, but I’ll suggest that’s less than ideal. Personally, I’d rather have the ‘Not Ready to Arm’ indication on the panel with the zone in violation being the deadbolt. I believe that can only be done with a switch in the deadbolt strike plate (like one of these... http://www.sdcsecurity.com/Latch-and-Deadbolt-Monitoring-Strikes.htm)

I don’t think Mobilinc yet understands how ISY sends values with decimal components.... This is new to v5 - and Wes I believe said he was going to wait until v5 got more stable before fixing these things...

AFAIK - even if you connect the Elk zwave module to an Elk - you still cannot use zwave sensors as alarm zones. This is because zwave is not monitored by the Elk, and it can be rendered useless by a The best solution I can think of. I believe there is a switch you can place in the deadbolt strike - you could wire such a switch to a native Elk zone to have the deadbolt drive an Elk entry/exit zone.

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!