Try entering easy.local in Chrome browser and see if the new UI loads. If you get to the login screen, use your ID portal login credentials.

If that works, you can also access pg3x from the menu. If it doesn't, open a support ticket with UD to get things straightened out.

Great idea. It doesn’t ask for a secondary set of credentials. It’s eisy.local though. Gotta love auto correct.

Well, that pushed the project ahead. It let me install Virtual, and now Admin Console has new virtual thinginess in the menu. Now I gotta read up on what it expects me to provide for addresses, etc. so I can create one. Thanks a bunch, @DennisC !

Great! I put an example of one in an earlier post. There is still something wrong with your credentials to sort with UD.

Edited yesterday at 02:58 AM1 day by hart2hart

3 hours ago, hart2hart said:

Great! I put an example of one in an earlier post. There is still something wrong with your credentials to sort with UD.

Hah! UD has already shrugged the ticket, advising me to get in the side door exactly as @DennisC did!

Edited 21 hours ago21 hr by lhranch

Following the tutorial I found here, I managed to beat my new configuration about the head and shoulders enough to get the Virtual Controller and my generic dimmer to go visible in Admin Console. Success!

I had two questions for those with experience in these switches, as virtual dimmers don't seem to present exactly as physical dimmers do.

First, the syntax allowed in the program is different for the physical and virtual dimmers. The physical dimmer has controls called Fade Up, Fade Down, and Fade Stop. The virtual one has Brighten, Dim, and nothing comparable to stop. Is this expected?

Second (and this seems to be a quirk of MobiLinc Pro only) the brightness reported for this switch is fugazi. On is 40%, whether I turn it on directly or it inherits from the scene when the driving device is 100%. Brighten takes it from 0% straight to 40%, Dim does nothing. Did I define the dimmer incorrectly or incompletely? (EDIT: to be clear, the values shown in Admin Console make perfect sense; it's the values shown in MobiLinc Pro that are wacky.)

Edited 19 hours ago19 hr by lhranch

On 12/25/2025 at 7:46 AM, larryllix said:

This doesn't sound logically congruent for three hardware devices to be combined into one software equivalent pseudoStatus device.

My mind did not necessarily perceive any logical dissonance, but I suppose that I could find some if I looked hard enough. The inconsistency, in my mind, were I to seek it out, would be that controlling a physical switch from the admin console or via UD Mobile does NOT trigger control conditions, but similarly controlling a virtual switch DOES. Even if true, it does not logically bother me that the control signal is triggered by contacts versus status being driven some other part of the switch.

To me, it is just a case of understanding how things work and exploiting capabilities for my benefit. For me, the virtual switch offers a valuable ability to add it to the UDMobile and mimic a physical switch, including status indications and triggering programs. (I also like the virtual switch in place of variables when used for simple binary logic conditions.) Without the virtual switch, one had to go through a bit more cumbersome approach to turning on and displaying scene status. No more trying to figure out when a scene is ON or OFF by use of some percentage or using a canary device within the scene.

I would, in fact, be disappointed if the virtual devices did not trigger control conditions or behave like physical devices as scene controllers.

The other hidden benefit of looking for control events (instead of status change) is that it allows you to separate the status display from triggering action. In other words, you can have a program update the status of that device, which will show in UD Mobile, without triggering the control event that you would get by pressing a button on it. Updating the status triggers a status change, but not a control event. This is the same benefit that you get with Keypadlincs.

13 hours ago, lhranch said:

Well, that pushed the project ahead. It let me install Virtual, and now Admin Console has new virtual thinginess in the menu. Now I gotta read up on what it expects me to provide for addresses, etc. so I can create one. Thanks a bunch, @DennisC !

Since at least the release of v6.0, the recommended method for accessing pg3x is from eisy.local. In fact, using any other method involving port 3000 potentially impacts some plugins. Using the local port causes some plugins, including Elk, to disconnect and than reconnect. This is also the case if you access pg3x from UD Mobile using a local connection. It is something UD is working to correct.

As for login credentials, UD is moving to single sign on concept. Currently, for the Launcher & eisy.local you use your portal credentials.

Using ssh, remains the original a**** credentials.

Connecting locally, by directly downloading the admin console is still your local credentials.

Hope that helps.