wmcneil

Update: After restarting the Caseta node server, shade device status seems to be updating promptly in AC.

I observe that updates to a shade status (posiition) that occur from a physical pico remote or the Lutron mobile app are not reflected in IoX for what appears to be a very long time. Is there a way for an IoX program to force a query?

Yes, using multiple device commands in an IoX program results in them being executed sequentially, so the multiple shades are not synchronized. Yes, I tried creating Lutron scenes and that works to keep the multiple shades in sync.

In my eisy, the pico-main device has no available status that a program could use. The pico-fav device does have available status. It is certainly possible to have an IoX program control multiple shade devices at the same time. I have tried this, and it works. The shades do not move together in nearly perfect synchronization as they do when the physical pico remote is controlling them, but they do arrive at the requested setting. I tried using an IoX scene to group the shades. That did not work well. Not all the shades moved properly, and the status of shades became confused in IoX

I have a Pico PJ2-3BRL which is programmed to operate multiple Lutron shades simultaneously. I am using a Lutron L-BDFPRO2 hub. After installing the Caseta nodeserver, the IoX AC shows two pico devices, a pico-main and a pico-fav (each shade is also present as a separate device). The pico-main has no available commands or status. The pico-fav has six available settings for "send command": On Off Brighten Dim FastOn FastOff. How in IoX can I perform the equivalent of, for example, pressing the Open button on the physical Pico remote?

Yes, there are a least a couple ways to bridge it over, either electrical relay or audio detection.....I'm trying to figure out how much is or is not possible with the alarm.com hardware....I'm a long time eisy and blue iris user, and the alarm.com system is really "against my religion".

I have purchased a home which has alarm.com sensor hardware (mostly zwave), and a Qolsys IQP4003 panel. If anyone has found a path to control at least the security functions via eisy I would be most interested. The alarm.com is a closed system, and even with the subscription, there are some huge missing features. Like no bridge between the smoke alarms and the security panel!

The credentials that are required are a function of what port you are attempting to access, not what method you are using to access the box. Here is a summary: Access methods available with any version of IoX: Interface protocol port Credentials Invocation --------------- -------- ---- ----------- --------------------------------- AC http 8080 local start.jnlp -> http://BOX_IP_ADDRESS:8080 AC https 8443 local start.jnlp ->https://BOX_IP_ADDRESS:8443 Additional access methods available when IoX >= 6.0.0 : Interface protocol port Credentials Invocation --------------- -------- ---- ----------- --------------------------------- EISYUI http 80 ISY_Portal http://BOX_IP_ADDRESS EISYUI https 443 ISY_Portal https://BOX_IP_ADDRESS AC http 80 ISY_Portal start.jnlp ->http://BOX_IP_ADDRESS AC https 443 ISY_Portal start.jnlp ->https://BOX_IP_ADDRESS

UD asked me to upgrade packages and try again. I did so and then tested with three users defined (user 2 and 1, as well as the default user 0 which is reserved for manual turns of the deadbolt) Everything seems to be working correctly now. These are the updates that were applied: IoX 6.0.3_3 -> 6.0.4_1 UDX 4.2.0 -> 4.2.0_2 PG3x 3.4.6 -> 3.4.9

I have opened a ticket. Michel responded and reported that myself and another user reported the problem. UD is investigating root cause.

Yes, the update to 6.0.3 happens on any reboot, without having pressed the update button. More info about that here: https://forum.universal-devices.com/topic/46113-reboot-automagically-causes-update-to-iox-603_3/#findComment-400793 There are additional upgrades available(to UDX 4.2.0, PG3x 3.4.6, and easyui 0.8.5), I have applied them, and the problem with my kwikset deadbolt user number reporting remains.

Thanks, yes, I have now fixed the version number in my post.

I have an eisy running IoX 6.0.3_3, and the zmatter dongle. I have a kwikset zwave 620 deadbolt. The deadbolt has been in my zwave network for over 1 year. The following behavior has started recently: When the deadbolt is unlocked by a human entering any valid user code on the keypad, the User Number reported in the Access Control Alarm entry in the AC is a 10-digit number. It is a constant value, regardless of which user code is entered. Previously, the User Number would be the correct user number corresponding to the code that was entered. Since the 620 supports only 250 users, a 10-digit number should not be possible. Before I start trying to chase this further, I thought I would see If anyone else has seen this behavior. If so, please post. Thanks.

@mmb, I also had the same problem with Firefox. Completely clearing the cache solved the problem for me.

@bmercier, since your statement above that "There are no cases where updates would be done automatically" is not correct (per Michel's response above), if possible, please remove the Solution tag from your post further above.

Explanation from Michel in response to the ticket I opened as to why 6.0.3 installs automatically upon reboot (without update button having been pressed): "...the reason is that 6.0.0 had an issue with libxml-2 library. So, once the packages were upgraded, it would no longer start and thus would not even give you the ability to login to the Admin Console to do the upgrade. Since we removed the capability for upgrade using the front power button (it had its own issues), our only choice was to reinstall it upon reboot. "

I have opened a ticket. Will post back with update once it is resolved.

It seems likely that the update to 6.0.3 is happening "automagically" on reboot without the update button having been pressed. If anyone else has experienced this, please post and let me know, so I can be absolutely certain before I open a ticket.

Hmmm, this happened on two different boxes, an eisy, and a polisy. In both cases, prior to the reboot, they were running IoX 6.0.0_4 . I could see that maybe I accidentally clicked on update on one of the boxes without realizing it, but seems less likely that it happened on two different boxes. The only package that actually "automagically" updated was IoX, so if your theory is correct, I would have had to accidentally done the update on both boxes before about 12/1, otherwise other packages would have updated too....Anyway, thanks for the pointer, good to know.

Rebooting either an eisy or a polisy (yes, I have both) that is running IOX 6.0.0_4 causes an update to 6.0.3_3 , WITHOUT any update being requested. Why is the update occurring when no update was requested? After the reboot and automagic update to IOX 6.0.3_3, eisy-ui / settings / system shows the following additional updates now available: UDX available update from 4.0.4 to 4.2.0 PG3X available update from 3.3.23 to 3.4.6 eisy-ui available update from 0.7.2 to 0.8.5 There is no release announcement for IOX 6.0.3 . Will there no longer be release announcements?, or was the one for 6.0.3 an accidental "miss"?

I was able to update my polisy to IoX 6 without any issue. It does take a while for the update to complete, maybe 15ish minutes.

So if I change local connection settings to use port 8080 and the "IoX" credentials (instead of the ISY Portal credentials), the problem goes away. @Javi , I assume UD Mobile will eventually fix this and support ISY Portal credentials on port 80, since not doing so would make UD Mobile inconsistent with all the other interfaces?

In UD Mobile (android, version 1.4.6) when I attempt to access Settings / Plugins I am getting this error message: "could not get pg3 auth Invalid Credential. Please check username and password. 401" This is an eisy running IoX 6.0.0_4 and eisyui 0.7.2 UD Mobile Local Connection Settings: Local IP Address: http://Numeric_IP_address Local Port: 80 Local Username: ISY Portal Username Local Password: ISY Portal Password

@johnjces, with regard to port 8080, it is available as follows, this may be what you were trying to remember: When using local credentials, you can access the REST interface using http at port 8080, for example: http://IoX_Username:IoX_Password@BOX_IP_ADDRESS:8080/RESTcommand When using ISY Portal credentials, you can access the REST interface using http at port 80(which is the default http port, so it does not have to be explicitly specified), for example: http://ISY_portal_username:ISY_Portal_password@BOX_IP_ADDRESS/RESTcommand

@bmercier, I am running 0.7.2 I have opened a ticket and attached the requested files to it.