Replies: 4 comments 3 replies
-
|
I haven't done this before, but I think the first things I would do are:
1) create backups of the yaml and json files (scenes, devices)
2) do a modem sync (to create all the links the modem needs to interact
with your devices)
2a) you might have to edit the scenes.yaml file to remove group #'s on
all the modem entries per the instructions for the scenes.yaml file, but I
think that might not be necessary in this special case of a virgin modem
2b)if you do remove modem group #s in the scenes.yaml file, remember to
remove the colon also (e.g., - modem: 32 => - modem)
3) do a join/pair/refresh/sync actions on each device - I think the
join/pair is needed to allow the modem to have the control needed to do the
rest
4) you also have the options of sync_all and dry_run; I personally wouldn't
take the sync_all leap right away and I think I would do a dry_run first on
a few devices to gain confidence it was going as expected.
I probably missed something here, but off the top of my head it's an
outline of what I would do.
…On Thu, Aug 3, 2023 at 6:40 AM Kevin P. Fleming ***@***.***> wrote:
A recent series of power outages and brownouts has caused one of my USB
PLMs to stop operating properly; a replacement should be arriving today.
I'm curious about the process of doing the replacement, as I understand
that some other (non-Home-Assistant related) Insteon control systems handle
this 'automatically' and re-join/pair all of the known devices, and setup
scene links after doing that.
I don't expect insteon-mqtt to work this way, of course, I realize that
I'll need to run a series of commands to get all of my devices linked to
the new PLM. Presumably these would be the same commands that were used to
link them originally!
Will I need to 'touch' the devices to enable this, or can this all be done
from the PLM side? Some of the devices are embedded in electrical boxes and
getting access to their buttons is challenging (fan controllers, in
particular).
—
Reply to this email directly, view it on GitHub
<#513>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACSR2ENZAURAASKC2U672YDXTN5YHANCNFSM6AAAAAA3CSF4JA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
That's pretty much what I expected :-) I don't need to take backups as all of the insteon-mqtt config files are managed by Ansible in my network, so I can regenerate them at will and change anything needed quite easily. I'm really hoping I can do the join/pair operations without requiring physical access to the devices. I'm pretty sure I was able to do that before, so fingers crossed! |
Beta Was this translation helpful? Give feedback.
-
|
OK, I have results. First: physical access is not required for line-powered devices. It is required for battery-powered devices, because you need to use the 'set' button to repeatedly awaken them so they will accept commands. Second, what did not work: Third, what did work: a shell Battery-powered devices are tricky; waking them requires using the 'set' button, but then joining disables 'set' mode, and they can go to sleep again (at least my Mini Remote did). Be prepared to wake them up a few times (and use the I believe my network of devices is fully operational now; linked devices (non-modem scenes) are working as expected, device changes are being reported to MQTT, and I'm able to control devices over MQTT. |
Beta Was this translation helpful? Give feedback.
-
|
How much time elapsed between running Running Insteon commands across multiple devices has always been very flaky. I tend to let the network "rest" for a bit after running any network wide commands. I have no idea why this helps. As for battery operated devices, there is no other way. The commands do get queued, but queued commands only seem to work ~50% of the time, and queuing multiple commands makes it even worse. Glad you got everything working. |
Beta Was this translation helpful? Give feedback.
-
|
The |
Beta Was this translation helpful? Give feedback.
-
|
As far as visiting devices is concerned, I think the battery devices are a
concern. Their commands are queued and "should" execute when the device
awakes periodically, but that will take time. I have also had trouble
with some of the motion sensors accepting sync commands even with the
device in hand and right next to the PLM modem, so by my experience, that
part may not be trouble free.
…On Thu, Aug 3, 2023 at 3:34 PM Kevin P. Fleming ***@***.***> wrote:
That's pretty much what I expected :-)
I don't need to take backups as all of the insteon-mqtt config files are
managed by Ansible in my network, so I can regenerate them at will and
change anything needed quite easily.
I'm really hoping I can do the join/pair operations without requiring
physical access to the devices. I'm pretty sure I was able to do that
before, so fingers crossed!
—
Reply to this email directly, view it on GitHub
<#513 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACSR2EKK5GGY3PGD4OPCSCTXTP4LLANCNFSM6AAAAAA3CSF4JA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
That is all about what I expected. You can see my comment on battery
devices crossed in the mail!
…On Thu, Aug 3, 2023 at 8:27 PM Kevin P. Fleming ***@***.***> wrote:
OK, I have results.
First: physical access is not required for *line-powered* devices. It is
required for *battery-powered* devices, because you need to use the 'set'
button to repeatedly awaken them so they will accept commands.
Second, what did not work: join-all, pair-all, and sync-all --run were
not successful. There was so much traffic on the Insteon network that
things got confused and some devices did not get joined or paired.
Third, what did work: a shell for loop over all the devices, running join,
then pair, then refresh, then sync --run.
Battery-powered devices are tricky; waking them requires using the 'set'
button, but then joining disables 'set' mode, and they can go to sleep
again (at least my Mini Remote did). Be prepared to wake them up a few
times (and use the awake command as well).
I believe my network of devices is fully operational now; linked devices
(non-modem scenes) are working as expected, device changes are being
reported to MQTT, and I'm able to control devices over MQTT.
—
Reply to this email directly, view it on GitHub
<#513 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACSR2EIUZDZW54C54426N4LXTQ6YNANCNFSM6AAAAAA3CSF4JA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
A recent series of power outages and brownouts has caused one of my USB PLMs to stop operating properly; a replacement should be arriving today.
I'm curious about the process of doing the replacement, as I understand that some other (non-Home-Assistant related) Insteon control systems handle this 'automatically' and re-join/pair all of the known devices, and setup scene links after doing that.
I don't expect insteon-mqtt to work this way, of course, I realize that I'll need to run a series of commands to get all of my devices linked to the new PLM. Presumably these would be the same commands that were used to link them originally!
Will I need to 'touch' the devices to enable this, or can this all be done from the PLM side? Some of the devices are embedded in electrical boxes and getting access to their buttons is challenging (fan controllers, in particular).
Beta Was this translation helpful? Give feedback.
All reactions