Problem after update EISY 5.5.4

MJsan · February 5, 2023

After the latest update posted... I now have 5 "bad actors" out of 23. They are fully accessible and work with MagicHome app... but just will not play with the UD portal.

I deleted everything on EISY- re-added MagicHome Node Server, and discovered nodes. Only 18 were showing up. I manually added the 5 that didn't show up, but they just won't work with UD Mobile or UD Portal. They are fine with Magichome app.

Any ideas?

bpwwer · February 5, 2023

Make sure those 5 devices are configured to allow local access.

MJsan · February 6, 2023

How do I enable that? It’s not apparent on the MagicHome setup? You’re right those 5 show local network offline, cloud online.

thanks for helping!!!

bpwwer · February 6, 2023

It is a setting in the MagicHome app. Somewhere under the device settings I believe.

MJsan · February 7, 2023

I see it but it’s not a setting - it just shows whether local network is online or offline. I get this message when I tap it.

many of my lights change from showing local network online or offline. I’ve got a mesh WiFi with 4 access points and everyone shows great signal at the router, everyone is on the same network, and magichome app can 100% control all of the lights.

I’m not getting why the MH poly isn’t able to control when the MH app can?

bpwwer · February 7, 2023

I don't really know what triggers the device to be locally online vs. offline. But if it's not locally online, the node server can't discover it.

MJsan · February 8, 2023

Strange. Tonight the program timer ran at 530pm and every one turned on (and they all are showing locally online right now).

I’ll keep an eye on it but it looks like they don’t stay locally online all the time - yet MH app can still address them. Is there some way to “wake up” to keep them online locally?

I have several versions of the MH controller and a few of them are bulbs without separate controllers.

larryllix · February 8, 2023

10 hours ago, bpwwer said:

I don't really know what triggers the device to be locally online vs. offline. But if it's not locally online, the node server can't discover it.

I think the local vs online is just inside the app. IIRC When the "online" bit is set in the request packet sent, the bulb doesn't respond with a confirmation, . This makes it faster for animations also.

IIRC a long click on the device in some apps will get you the device settings.

Some of the apps will not allow local control. I always had to use the fluxnet app to achieve no cloud connection.

Edited February 8, 2023 by larryllix

MJsan · February 14, 2023

@larryllix thanks for that insight ... I can't get Fluxnet app on IOS, so am stuck with MagicHome. The device settings are in a separate menu and there's no way to set local network on .. it's either there or not.

Now for the fun part... it changes throughout the day. The last few days, things work fine. What I'm seeing this moment is attached. Everything is showing up OK for cloud, but only a few items are "local" online. When I go to the MH app, everything shows up accurately and can be turned on / off just fine. When I try to do that from UD Mobile app, some (most) of the ones with local dimmed (offline) will work. The UD portal shows them connected=true.

It's just weirdly flaky. The program to turn on all of these access lights runs nightly, and I have it set to repeat the "ON" command for the scene 5 times (30 seconds apart) just to be safe. Same for the OFF event later on. The last two nights, 100% of the lights behaved, 3 nights ago, 1 didn't come on (out of 23) and before than 2 didn't go off.

It would be awesome if there could be some kind of handshaking / acknowledgement like Insteon does to ensure that when ON is sent, it's actually done. I'll keep an eye on it and hopefully we can find a way to make it stable?

Cheers and THANK YOU ALL for your help!

larryllix · February 14, 2023

How old is your router ?

I had an ASUS router AC92u? that was short of memory and it started doing really strange things around the 51 devices mark. Unknown to me, ASUS doubled the NVRAM in the later released model. I spent a few years fighting with it before buying four new ones that all had bugs in them also. All my MH protocol bulbs and strips work 99% now. However I use my own software bridge.

Sent from my SM-G781W using Tapatalk

MJsan · February 17, 2023

I'm on a pretty beefy Ubiquity UniFi Dream Machine Pro router/firewall with 4 access points in a mesh config, so I don't think it's on the network side... plus the MagicHome and FLuxWiFi apps and GoogleHome work 100% of the time perfectly.

I went out of town for work for a few days and OF COURSE the lights went wonky. About 1/3 of them worked, and my husband is NONE TOO HAPPY. I believe the exact words were "it all worked fine before, why did you have to mess it all up trying to make it better?"

WAF/HAF not good here.

I'm playing with it now. Activate scene from UD mobile ... 1/3 of the lights respond to that scene. Trying individual lights - got a few more to turn on. I have a few other lights not part of this scene - and they aren't behaving with the UD mobile app.

MagicHome Pro and Flux WiFi apps (have both) work 100% perfectly.

I'm at a complete loss here ... why does this NS only work sporadically (and completely unreliably) while the APPs work locally perfectly (iPhone, iPad, Mac) ??????

This is really frustrating because I don't know where to focus my efforts on - is this the Node Server? Is it the EISY? Things were working pretty well for a week or two, but "went to hell" after 5.5.4.

Well, the fun just continues... I can't access UD from console - it's showing up but no option to login to console. https://eisy.local:8443/desc is blank, had to re-add manually keying in IP. But it works from the mobile app. ARGH.

@Michel Kohanim is this just me struggling with this stuff?

I'm getting increasingly frustrated... so much so that I'm debating on experimenting with HA to see if maybe that's a more stable platform?

Ugh.

Edited February 17, 2023 by MJsan

MJsan · February 17, 2023

Looking at one specific device that isn't behaving ...

MagicHome sees it, controls it, and it's showing cloud and local online...

image.png.63857855fba9e29e338c07b35caf9961.png

UD shows it blanked out...

Same is true for about 10 other lights.

I've tried querying ... rebooting EISY ... rebooting router ... and it's always the same. UD doesn't "see" the light, MH/FW app sees it and can control it perfectly. Router sees all of the lights as well. Google Home (through speakers and app on phone) controls perfectly.

Edited February 17, 2023 by MJsan

DennisC · February 17, 2023

eisy is currently running v5.5.6 and you mention 5.5.4, is that what you are currently running? If so, maybe an upgrade will correct your issue?

If you decide to update, be sure to take a backup first, in case you need to restore it.

bpwwer · February 17, 2023

@MJsan I haven't had any problems with the MagicHome node server but I only have 2 lights set up. Node servers and PG3 both maintain log files that can provide a lot of information that will help with troubleshooting problems.

I suspect that if you look in the node server log, you'll see that for the lights that aren't working, the node server says it can't connect to them. From my (granted, very limited) experience, it seems like the cloud connection is much more stable than local connections which is why the app always seems to work.

MJsan · February 17, 2023

Updated packages to 5.5.6 and now I'm getting this fun error

@bpwwerI looked at the network traffic and didn't see any traffic from outside going to the 24 MH modules - not a single one - when I sent commands.

Taking a breath, resetting everything... and thanking myself for not selling all of the old Insteon plug-in modules that used to be in front of the MH lights ... I'm very close to putting those back in as they were reliable.

DennisC · February 17, 2023

4 minutes ago, MJsan said:

Updated packages to 5.5.6 and now I'm getting this fun error

@bpwwerI looked at the network traffic and didn't see any traffic from outside going to the 24 MH modules - not a single one - when I sent commands.

Taking a breath, resetting everything... and thanking myself for not selling all of the old Insteon plug-in modules that used to be in front of the MH lights ... I'm very close to putting those back in as they were reliable.

After I upgraded I received that message and it stopped after one or two reboots and several logins to admin console.

Also received repeated notices about upgrading packages that UD spent time troubleshooting and determined it was a bug.

MJsan · February 17, 2023

thanks @DennisC I was just going to reach out to @Michel Kohanimabout that ... getting the "you have upgraded packages" too ... just going to reboot a few more times.

Finally able to get to console, PG3 launches, "seems" to be working. Same problem. 16 of 24 nodes showing up with no data (as shown above) in console ... but perform perfectly with MH. I also watched network traffic again - there is ZERO outside traffic coming in to any of the MH modules when using MH app.

Edited February 17, 2023 by MJsan

bpwwer · February 18, 2023

I'm far from an expert on MH devices/app. I did create the current node server and like I said, it has been working well for me with the the 2 lights that I have.

Have you looked at the node server's log file? It can provide a lot of information about what the node server is doing and whether or not it is even able to communicate with the devices.

For example, in debug mode, I'll get these messages every few seconds as it checks the status of the lights:

2023-02-17 16:12:03,363 Thread-21705 udi_interface      DEBUG    rgbled:watcher: 70039f051de9: status 81 35 24 61 01 1E 00 00 00 00 07 FF 0F 6F 
2023-02-17 16:12:03,364 Thread-21705 udi_interface      DEBUG    rgbled:levelOf: levelOf input: 0 0 0
2023-02-17 16:12:03,365 Thread-21705 udi_interface.node DEBUG    node:setDriver: 70039f051de9:mh 192 168 92 94 No change in ST's value
2023-02-17 16:12:03,366 Thread-21705 udi_interface.node DEBUG    node:setDriver: 70039f051de9:mh 192 168 92 94 No change in GV1's value
2023-02-17 16:12:03,367 Thread-21705 udi_interface.node DEBUG    node:setDriver: 70039f051de9:mh 192 168 92 94 No change in GV2's value
2023-02-17 16:12:03,367 Thread-21705 udi_interface.node DEBUG    node:setDriver: 70039f051de9:mh 192 168 92 94 No change in GV3's value

So I know it's communicating with the lights.

MJsan · February 18, 2023

@bpwwermany thanks for your patience with me

I turned it on for DEBUG and this is what it gave me - shortpoll every few seconds and you'll see a few ON and OFF commands I sent from UD Mobile (which were not processed / no change in light):

2/17/2023, 16:25:10 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_5] {"shortPoll":{}}

2/17/2023, 16:25:13 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_1] {"shortPoll":{}}

2/17/2023, 16:25:15 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_5] {"shortPoll":{}}

2/17/2023, 16:25:20 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_5] {"shortPoll":{}}

2/17/2023, 16:25:24 [pg3] info: [00:21:b9:02:5f:c1(1)] ISY HTTP Inbound: Received DON for node: 2494942f9da9

2/17/2023, 16:25:24 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_1] {"command":{"address":"2494942f9da9","cmd":"DON","query":{}}}

2/17/2023, 16:25:24 [pg3] info: [00:21:b9:02:5f:c1(1)] ISY HTTP Inbound: Received DON for node: 2494942f9da9

2/17/2023, 16:25:24 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_1] {"command":{"address":"2494942f9da9","cmd":"DON","query":{}}}

2/17/2023, 16:25:25 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_5] {"shortPoll":{}}

2/17/2023, 16:25:30 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_5] {"shortPoll":{}}

2/17/2023, 16:25:35 [pg3] info: [00:21:b9:02:5f:c1(1)] ISY HTTP Inbound: Received DOF for node: 2494942f9da9

2/17/2023, 16:25:35 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_1] {"command":{"address":"2494942f9da9","cmd":"DOF","query":{}}}

2/17/2023, 16:25:35 [pg3] info: [00:21:b9:02:5f:c1(1)] ISY HTTP Inbound: Received DOF for node: 2494942f9da9

2/17/2023, 16:25:35 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_1] {"command":{"address":"2494942f9da9","cmd":"DOF","query":{}}}

2/17/2023, 16:25:35 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_5] {"shortPoll":{}}

2/17/2023, 16:25:37 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_5] {"longPoll":{}}

I put it into DB Debug and did the same thing ... one more item "silly" popped up, no clue what that means:

2/17/2023, 16:29:37 [pg3] info: [00:21:b9:02:5f:c1(1)] ISY HTTP Inbound: Received DON for node: 2494942f9da9

2/17/2023, 16:29:37 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_1] {"command":{"address":"2494942f9da9","cmd":"DON","query":{}}}

2/17/2023, 16:29:37 [pg3] silly: SELECT Node Server.*, COUNT(node.address) as nodeCount FROM Node Server LEFT OUTER JOIN node USING (uuid, profileNum) WHERE (uuid, profileNum) is ('00:21:b9:02:5f:c1', 1.0) GROUP by Node Server.profileNum

2/17/2023, 16:29:37 [pg3] info: [00:21:b9:02:5f:c1(1)] ISY HTTP Inbound: Received DON for node: 2494942f9da9

2/17/2023, 16:29:37 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:21:b9:02:5f:c1_1] {"command":{"address":"2494942f9da9","cmd":"DON","query":{}}}

2/17/2023, 16:29:37 [pg3] silly: SELECT Node Server.*, COUNT(node.address) as nodeCount FROM Node Server LEFT OUTER JOIN node USING (uuid, profileNum) WHERE (uuid, profileNum) is ('00:21:b9:02:5f:c1', 1.0) GROUP by Node Server.profileNum

You can see that 5 lights are reporting 0% (off) but the rest are blank. I see them on my network router, can turn them on/off via MH, so I know they are "alive" but they are just dead/invisible to the Node Server.

Edited February 18, 2023 by MJsan

MJsan · February 18, 2023

BTW- seeing this on the PG3x window ... I've updated packages 4 times today and am at 3.1.22, so it's not getting 3.1.23. Could that be part of the problem @Michel Kohanim?

MJsan · February 18, 2023

So MH has a timer function in the app, I’m falling back to that and their scene function. It is working (day 1) so I’m going to rely on that until EISY is working.

I’ve been following some of the HA developments and can’t tell if these problems exist over there as well… so will use this bandaid and wait and see if things improve.

bpwwer · February 18, 2023

17 hours ago, MJsan said:

BTW- seeing this on the PG3x window ... I've updated packages 4 times today and am at 3.1.22, so it's not getting 3.1.23. Could that be part of the problem @Michel Kohanim?

No, 2.1.23 is still in release testing and nothing in that would be related to this issue.

Can you check the node server log (dashboard -> MagicHome details -> log and set that one to debug. Try the on/off commands again and either post the results of that log or download a log package an PM it to me.

MJsan · February 18, 2023

@bpwwer thanks much... here's what I have - debug log DebugLog.txtand device node list Nodes.docxattached.

As of this AM only 5 lights are showing up with status on UD portal

When I did an "ON" command for "Glass Cabinets 2" (dc4f2287449c) I did see an error in the log saying node address does not exist. Double checked the device node list and it's there (same address reported in portal too).

2023-02-18 10:47:13,684 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message command
2023-02-18 10:47:13,684 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING command
2023-02-18 10:47:13,684 Command udi_interface.interface ERROR interface:_handleInput: _parseInput: node address dc4f2287449c does not exist. {'address': 'dc4f2287449c', 'cmd': 'DON', 'query': {}}

Same thing for Marc Office (2494942f9da9).

Turning on Wine (dc4422c5899f) works as expected and the log shows this:

2023-02-18 10:46:56,217 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message command
2023-02-18 10:46:56,218 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING command
2023-02-18 10:46:56,218 Command udi_interface DEBUG rgbled:commandQueueAdd: recieived command {'address': 'dc4422c5899f', 'cmd': 'DON', 'query': {}}
2023-02-18 10:46:56,596 Thread-20 udi_interface DEBUG rgbled:commandQueue: process command {'address': 'dc4422c5899f', 'cmd': 'DON', 'query': {}}
2023-02-18 10:46:56,596 Thread-20 udi_interface DEBUG rgbled:send: sending message 71
2023-02-18 10:46:57,224 Thread-19 udi_interface DEBUG rgbled:watcher: dc4422c5899f: cmd response? f0712485
2023-02-18 10:46:57,522 Thread-20 udi_interface DEBUG rgbled:send: sending message 81
2023-02-18 10:46:57,523 Thread-20 udi_interface DEBUG rgbled:readBulb: dc4422c5899f: request status
2023-02-18 10:46:57,533 Thread-19 udi_interface DEBUG rgbled:watcher: dc4422c5899f: status 81 33 24 61 01 0F E1 FF 00 00 04 00 00 2D
2023-02-18 10:46:57,533 Thread-19 udi_interface DEBUG rgbled:levelOf: levelOf input: 225 255 0
2023-02-18 10:46:57,534 Thread-19 udi_interface.node DEBUG node:setDriver: dc4422c5899f:192.168.7.97 No change in ST's value
2023-02-18 10:46:57,534 Thread-19 udi_interface.node DEBUG node:setDriver: dc4422c5899f:192.168.7.97 No change in GV1's value
2023-02-18 10:46:57,534 Thread-19 udi_interface.node DEBUG node:setDriver: dc4422c5899f:192.168.7.97 No change in GV2's value
2023-02-18 10:46:57,534 Thread-19 udi_interface.node DEBUG node:setDriver: dc4422c5899f:192.168.7.97 No change in GV3's value
2023-02-18 10:46:57,534 Thread-19 udi_interface.node DEBUG node:setDriver: dc4422c5899f:192.168.7.97 No change in GV6's value
2023-02-18 10:46:57,534 Thread-19 udi_interface.node DEBUG node:setDriver: dc4422c5899f:192.168.7.97 No change in GV7's value
2023-02-18 10:46:57,534 Thread-19 udi_interface.node DEBUG node:setDriver: dc4422c5899f:192.168.7.97 No change in GV8's value
2023-02-18 10:46:57,534 Thread-19 udi_interface.node DEBUG node:setDriver: dc4422c5899f:192.168.7.97 No change in GV9's value
2023-02-18 10:46:57,534 Thread-19 udi_interface.node DEBUG node:setDriver: dc4422c5899f:192.168.7.97 No change in GV10's value
2023-02-18 10:46:57,535 Thread-19 udi_interface.node DEBUG node:setDriver: dc4422c5899f:192.168.7.97 No change in GV5's value

Any insights from all of this? It feels like there's a bug somewhere that node addresses that are there aren't ???

bpwwer · February 19, 2023

I see some of the problem. When you run discover on the node server, it tries to discover all of your bults/strips. For the devices it finds, it adds to it's internal list. It will then create nodes for any new bulbs/strips that it discovers. However, it doesn't delete nodes that were found at one time but not found with the current scan.

This means that the list of nodes in the AC may not represent the list of nodes that the node servers is currently communicating with. The nodes that aren't showing status aren't in the internal list which is why it reports not found when you try to control them.

The question is why isn't it discovering all the devices? I don't know. But you do have the option of manually adding them to the node server via the configuration screen. That may solve the problem or, if it really can't communicate with the device, you'll just get a different error, instead of not found, it will be a failed communication error. But it's worth a try.

MJsan · February 21, 2023

@bpwwer But the nodes are there (MH sees them??)

is there any correlation to this reported problem with the LIFX problem after 5.5.4?

Things were slightly flaky pre 5.5.4 (1-3 lights would not behave) but after 5.5.4 it all went to hell and now only 1-4 lights are working with Eisy. And it’s not the same 1-4 lights, it changes during the day and depending on if I’ve reset (sometimes multiple times).

I’m going out of the country for the next 10 days. I’ve shown my husband how to use the MH app (which again works 100% reliably), I’ve set up timers on MH that match what I had on EISY, so things should work while I’m gone.

insteon switches and keypads are all pretty much self-contained and control what they are linked to, so for all intents and purposes I’m not using EISY anymore.

if any ideas on how to fix this come up please post so I can try to rebuild this when I get back … otherwise I’m really considering why to continue with EISY , other than act as the back-end for Google Assistant voice control for Insteon (and for that why not dig up my old Insteon hub?).

the whole reason to pay $$$ and invest the many hours in migrating to EISY was to integrate MH, Insteon, and Google Assistant and have a decent (single) mobile app for MH and Insteon devices.

many thanks for your help and patience (and for letting me rant). I’m just super frustrated

Edited February 21, 2023 by MJsan

Sign In

Problem after update EISY 5.5.4

Recommended Posts

MJsan

bpwwer

MJsan

bpwwer

MJsan

bpwwer

MJsan

larryllix

MJsan

larryllix

MJsan

MJsan

DennisC

bpwwer

MJsan

DennisC

MJsan

bpwwer

MJsan

MJsan

MJsan

bpwwer

MJsan

bpwwer

MJsan

Recently Browsing

Who's Online (See full list)

Forum Statistics

Browse

Activity