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