MJsan

Just to close this out ... after going through a bunch of gyrations and trials, the best way to "fix" this is to use the Google Home. It can activate MH scenes, so when we want those, we just speak it.. Kind of sucks that there's no way to activate MH scenes through EISY - or to directly address colors and functions but this appears to be the simplest, most reliable (albeit with a pretty significant lag - 21 lights go on over a period of about 10 seconds), and most "spouse acceptable" method I've been able to come up with. Now I've added a couple of Govee lights (thanks Amazon Pride Day) which are very cool, but the Govee poly doesn't work with them either. That's another thing Google Home was able to address - automations can directly address both MH and Govee in the same command. I *hate* not having everything addressable via a central app and having to go through multiple apps to control things (Automate for shades, MH for scenes, Govee for those lights, and Eisy for everything else) but with Google Home acting as the speech front-end, it works. I'm still fiddling with Home Assistant - it appears to be able to do everything I want to do, but it's a lot of work and time isn't something I have enough of for a while!

Yup ... it works exactly as expected. Guilty of overthinking it before doing it!!!!

@larryllix thanks for the details... I'm going to consider playing with it. What I'm really debating is going down the path of adding another rPI to my setup or trying to figure this out with HA.

I've searched and searched and can't seem to find this... Currently using Google Home and thinking about moving over (back) to Amazon Alexa. I want to try it out on a new Echo Show 1st ... is there a trick to getting both Google Home and Amazon Alexa to function at the same time while I test and migrate?

@larryllix I guess I'm missing something about how MH "scenes" are done - from what you said earlier, I think I undertstand that to mean that a "scene" executed on the MH app from my phone is just a blast of (in my case) 21 commands, i.e. "landing green 100%, hallway red 100%, cabinet yellow 100%" and so on. The way MH integrates to Google Assistant is that the "scenes" show up on Google as "automations" and when I call the automation from Google, it's REALLY slow - light...by.......light....by.........light" for all 21. It works in the end, but takes about 20 seconds for all of them to get to where they should be. MH from the app is instantaneous. Same for executing a group command from UD/EISY that includes MH nodes - they are almost instant. I tried - unsuccessfully - to read a tcpdump from my Mac using the MH app to see if I could see what network commands were going out. I'm quickly getting out of my wheelhouse ;( and couldn't interpret the gibberish. Any other ideas/thoughts on how to bring over those scenes into a NS would be **AMAZING** - and I truly thank you for putting so much effort and thought into this!

@Michel Kohanimit just happened again - not opening up a ticket because I was able to "fix" ... the EISY went offline (network went down for a few mins) and when it came back up, Magichome nodes weren't responsive. Looked at the PG3 log and saw it wasn't working. Did a REDISCOVER in the PG3 window, and after a few minutes of queries.... all works. I recall that's what I did last time - so at least for the last two instances a rediscover works?

Larry that’s what I’m finding. I need an in-between broker to do it. I can execute the MH scene from the MH app, IFTTT and also from Google Assistant … just can’t do it from UD

Yes but you can’t control the colors - the MH app lets you turn them on to specific values. I can turn on one light to sever different colors depending on the scene called for.

I've been playing with the MH app and really finding it to be pretty awesome. The ability to group lights into a Scene - with colors and brightness levels - is exactly what I want. I've got scenes setup for "All lights green" and "all lights blue" as well as "all lights on" (uses last setting) and "all lights off" What I haven't been able to figure out is how to trigger these scenes via EISY... I'm trying to drive everything through one app. I've figured out how to do it via HA but I am trying to keep it on EISY. Anyone have ideas on how to do that? @bpwwer @larryllix

@Michel KohanimI will as soon as it happens again. It's usually good for a 3-5 days, then acts up. Thanks man!!

I probably jinxed things with that last message I'm still having stability problems - system goes off-line, requires rebooting, and for PG3 I have had to "re-add" all nodes several times to "kick-start" it into recognizing nodes that go "unreachable" for no apparent reason. Life in the early adopter lane.

Yeah... customer support has been really above and beyond (as it usually is) and Michel is super awesome. Unfortunately, I had a hell of an install like you did. I think Michel spent a few hours in my system overnight to fix things (early install- back in March). The good news ... after a lot of bumps, I do have a stable system running. Now, during the "hell" I was going through, I did buy a HomeAssistant box and have been playing with it. Not that I'm going to migrate over, but because I want to learn... and just in case, have a backup/alternative. I like HA and it works with EVERYTHING I have (shades, ecobee, insteon, magichome, solar), but EISY is faster and more responsive -and after all the start-up issues, easier to manage and maintain - plus I like the mobile interface because it's cleaner. I've not delved into building HA screens yet (am a little afraid of it).

Hey @bpwwer and all those following ... Got back from a 2-week work trip and did a refresh (discover) and things seem to be populated with status now Did an update to 5.5.9 (and PG3x to 3.1.23) and things _still_ seem to be working. Scenes are firing as expected (which means Insteon KPLs are triggering Magichome LEDs... the whole point of this Let's see how well things keep working for a while, but apparently I'm back to running now.

@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

@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 ???

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.

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?

@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: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: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: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: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: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: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.

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.

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.

Looking at one specific device that isn't behaving ... MagicHome sees it, controls it, and it's showing cloud and local online... 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.

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.

Ok, let's try this a different way I have 24 lights now (added a new one). This scenario only pertains to that new light ... a ceiling light that has both warm white/cool white (acts like a regular light) and also RGB. I'd like to have that light participate in a scene with 23 others and come on to a soft green color like the others do via a scene (accent lights ON). All of the others are pre-set to their last-on state and don't change. BUT I want this new light to come on full white when the command for "overhead light" is issued - or come on green when ACCENT ON scene is issued. I have to believe there is some way to accomplish this. I can set each light individually in the MH app, why can't I send both the ON command and light color/intensity settings in a scene command? Hopefully I'm explaining it - if it's wishful thinking on my part that I could do this, then that's a wish and I'd love to see if others are trying to do similar types of things. With the availability of addressable, color LED lights, being able to set scenes with colors would be AWESOME. I may end up having to talk to @larryllix some more about a bridge software... maybe even migrating to HA? Thanks, MJ

@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!

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.