Javi

As far as I know it is a standard USB cable. I have not see reports stating otherwise.

While not exactly what you are looking for, the bulb can be set manually using UD Mobile in the Device's Dashboard (coming soon to favorites). Click the menu next to the Hue and/or Saturation properties and select the Hue or Saturation Sliders as the View Type.

Pinouts on generic USB -> RJ45 adapters do not match for Insteon PLMs so they will not work. The options are to build your own cable (instructions are posted somewhere on the forum) or purchase one from UD.

Are you seeing this outside of a Geofencing Screen? If only seeing this in a Geofencing Screen it is expected as the app cannot function without Always permission. The likely cause is the app previously requested that the user "allow always location" but either (1) the request was denied or (2) iOS may periodically alert users an app is using allways location which and give then the option to revoke. If the request is denied or revoked user must manually change this permission in iOS Settings before Geofence screens are shown in UD Mobile.

Great! The "Beta" is because it was installed from the "Non-Production" Store. I think you would need to copy the parameters then delete the Beta Version, then install the Production version in the same slot and replace parameters. I think if done like this it will preserve programs, but have not tried.

Might be related to the version, I've corrected in the database. Please try again....if it does not work reboot may be required first.

The preceding zeros in 2023.01.09 were causing issues with PG3 so they were removed. While I don't think the version is the cause of "Unknown Error" I think you can fix this by selecting the Plugin from the Non-Production Store (Beta), clicking install under "purchase in "Available Purchase/Install Options". Then next to "iTach-IR 2023.1.9 is already installed in slot X" select "reinstall here". For the "Unknown Error (see Logs)" there should be a few logs in the iTach Node Server. The error is likely prefixed with "ERROR : ". Download the iTach Log after and error is encountered then attache here for review. If this happens with the same commands then it it likely invalid formatting. If this happens randomly then it is likely a network issue, is this a WiFi iTach or hardwired?

Look Looks like a parsing error possibly caused by an invalid character. Please open a ticket and include eisy's UUID.

Some of the Favorite Types require that the Display Status is linked to a command, i.e. toggle needs to know status to send the opposite command. Command Type doesn't require a Display Node or Display Status. If need the Display Node Can be removed by clicking Display Node then pressing delete (top right) on the Node Selection Dialog.

We are working on a production version with (future) browser support. So I recommend holding any charges until released to production.

Great, no way the remote connection would have shown connected. My guess is the phone was connected to WiFi and was using the Local Connection Settings. The Local Connection Settings had the Local IP Address of an active system. So UD Mobile did connect just to the wrong system. In this case an error is only shown during synchronization when the UUID is validated.

Highly unlikely, more likely the system name does not match the UUID fo that system. Check Settings tab > Systems., Click the name of the system, check the UUID. If the system is no longer used it can be deleted or disabled (system settings at bottom of the same screen).

The toggle failure is likely related to the "Unknown" Status. My guess is UD Mobile issues the command but the status does not change or there is a communication issue with the Node Server. Assuming the door is closed when "Unknown" is encountered, does the status change if you click the tile's menu (3 dots) to go to the Device's Dashboard, then click the command to "Close"? If it does not change try pressing "Open" on the Device's Dashboard, does status change? Does the door open? If there is no status change and/or the door does not open then there is a communication issue try checking the Node Server Log or opening a topic in the Ratdgo subforum. If the status changes when pressing open form an "unknown" state then the default UD Mobile Toggle implementation will not work when the status is "Unknown" as it appears value for "Unknown" is higher (as an integer) than "Closed" so UD Mobile will send the close command when "Unknown" is encountered. If the last statement was true then there are a few options. Issue a direct command by pressing the tile's menu (3 dots) then trigger a direct command, i.e. "open". Create a custom toggle, our example is very similar to this situation. See https://wiki.universal-devices.com/index.php?title=UD_Mobile#Favorite_Examples Create 2 favorites command tiles which trigger open and close. (Beta) Create a custom tile. We will add a favorite type to remove the toggle indicator for these situations in a future version of UD Mobile.

Sounds like 2 separate issues. Status icon/color mismatch: Do you have a screenshot showing the mismatched icon/status? Commands not executed: An activity indicator (circular progress) should show on command execution. Do you see the indicator? Does it stay on the screen? Circle in Upper Corner (Toggle indicator): This should correlate to status. Normally filled is ON and empty is OFF. The toggle indicator should only appears on devices which have a Status named "Status", and both an On and Off command. While this works with most device types it is possible Status does not have a relationship to On and Off. In this case "default will not work" The app should allow users to switch the type to "Standard" for this unusual case, however I just noticed it fails on both Android and iOS wo will need to be fixed.

Thanks, please try upgrading UD Mobile to version 1.1.54 which should fix the Firebase dependency crash. Version 1.1.54 was approved for production release this morning and beta yesterday.

Please share a screenshot of the error or the error report. Not all functions were tested on Mac so it may be a compatibility issue. P.S. Also please upgrade UD Mobile to version 1.1.54 as 1.1.53 was crashing due to outdated dependency

HI @Kentinada, I fixed ambiguous error message for the next version. It should have read: "Firmware upgrade for Plugin Software (PG3) required to use this feature. Current version: <current version>. Required version <required version>. Would you like to upgrade now?" Where 3.2.17 is your current version and 3.2.19 is the required version. Force upgrade should upgrade the Plugin Software (PG3), as with any firmware upgrade this should be done while at the same location as eisy.

The latest version of PG3 added a permission for apps which access eisy which may be related. Is this check box available on enabled in the Node Server's configuration on web?

Depends on the Node Type. If this is a program/variable see: https://wiki.universal-devices.com/index.php?title=UD_Mobile#Program_And_Variable_Settings If not a program or variable, are there any errors attached (badged) to the UD Mobile bottom Home Tab? Do the values in UD Mobile differ from Admin Console? If true there is likley communication issues between controller - device.

I cannot replicate, if open to remote diagnostic please open a ticket and include your UUID. I'll provide instructions on remote access approval after I've added your eisy to the diagnostic portal. Can do it tomorrow or sometime next week.

@dbwarner5, The remote integration is Beta as it does not have all features, but the error should not happen. It may be related to the Allow ISY Access Parameter as this has not been added to UDM. What is your eisy and PG3 firmware versions?

The first thing to check is if this is a connection or read timeout. I've seen long connection times when multiple family members are streaming which is network related, not eisy related. Assuming read timeout: Not single threaded, but to maintain thread safe operations most software queues some request to a single thread. For example a program triggering notifications with variable substitution, we don't want the variable to change during substitutions. Busy can happen for many reason, such as large data queue when starting a new local subscription. Portal (remote subscription) has a single socket so it will request all values (rest) when a new client connects as it shares a subscription amongst clients. IMO a 30 second timeout local, 120 remote should be sufficient for both connection and read.

Both items are on our list in one way or another, although not sure on timeframe.

Beta 1.1.52 Updated Device Dashboard (aka Node Dashboard) cells and added new menu to select cell type. Added alpha Device Property History (aka Status History). During initial testing you must enable capture of status history, this will likely be enabled by default in a future firmware version. During alpha testing we are only trying to verify this does not overwhelm eisy, especially users with large systems. Chart options, improvements, and favorites tiles coming soon. See: https://wiki.universal-devices.com/UD_Mobile#Status_History

In short this is an insteon limitation with non-load bearing KPL Buttons. See Known issues: https://wiki.universal-devices.com/UD_Mobile#Scene_Estimated_Status . I updated Known Issues, but this issue has been discussed at length in the forum, so a search may shed light on some more detail. Not Possible, the only way this would happen is if you turn the Scene off/on not the Dimming Device...the scene cannot be dimmed to a percentage from the admin console. Even if using the "DIM" button a non-load bearing KPL Button will not turn off. It has always been possible to control a physical device outside of a scene. For example KPL buttons and fanlink commands (low,med.high,off), would be close to impossible.