jmbraben

After I did full update on my Polisy (from v12 to v13 of the OS), I noticed that my MagicHome node server was not working and posted here: But it appears to be deeper than that as the PG2 log is not running (and appears to have stopped after first reboot) and MagicHome stopped running after the second reboot, so looking for more system level help (please) I can log into the PG2 web interface and ssh to the Polisy, but the PG2 logs are doing nothing and the MagicHome node server is just "disconnected"...I've updated, uninstalled/reinstalled MagicHome and rebooted the Polisy a couple times. System appears to have updated as expected and noted nothing unusual in the process. [admin@polisy ~]$ uname -a FreeBSD polisy 13.0-RELEASE-p11 FreeBSD 13.0-RELEASE-p11 #21 releng/13.0-n244800-d7fd130ebe5: Wed Apr 6 17:54:11 UTC 2022 ec2-user@bsdev.isy.io:/usr/obj/usr/src/amd64.amd64/sys/POLISY amd64 Looking at dmesg, I've got a flood of "ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping" igb0: link state changed to UP ubt0 on uhub2 ubt0: <vendor 0x0cf3 product 0xe003, class 224/1, rev 1.10/0.02, addr 3> on usbus1 WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() Security policy loaded: MAC/ntpd (mac_ntpd) ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping

I've had Insteon since 2006 (2005?) and still have a few PLC "ICON" nodes around...but I've also had to replace almost every PLC only node due to power supply issues....the dual-band seems more reliable...or maybe I haven't had them as long. I used to think "Keypads are needed everywhere", but I've found Alexa/Assistant integration for triggering scenes works more intuitively (vs tiny fonts on buttons)...assuming your ISP doesn't fail you. That said, the multi-device scenes at the network/device level are going to be hard to replace. I guess if the switches themselves have a fast connection to the hub/controller, "maybe", but TBD.

yeah...pretty much what I'm thinking...everything already works by default stand alone anyhow (but ripping it all out would be no big deal either) Personally I see negative value in "professionally installed", but that is me. Just need to find nerd buyer Guess we'll see what happens.

Finally got through to Smarthome customer support, the rep stated that they "expect inventory next week and to be back to normal lead times"...hopefully that will be the case.

I'm currently in a similar boat...my current home has Insteon that I installed, now we're building new. Trying to figure out what I want to put in that house (and if the Insteon is positive or negative in current house). I don't want a closed system that I can't maintain myself, but I'm currently on hold with Smarthome trying to understand what is going on with Insteon availability (if you haven't noticed, most SKU has not been in stock for several months).

I second this...I moved some equipment around a while ago and the ISY went from vertical inside a panel to flat on a shelf...and my Zwave devices stopped working. The range went from "no problem" to literally 5 feet. The flat orientation doesn't work...mounted it to a wall vertically and all was good again.

Not disagreeing, but if this is a "feature", I'd hope for a clearer indication. Also why my home automation lives on separate vlan... building walls works both ways (says the guy that had his whs server ransomwared last year)

I'd gotten lazy because the isy is on an isolated vlan...I've been accessing the admin console through the UD portal (rather than local direct lan access). Connecting to the isy locally let me run the update...I was unaware that trying to update via the portal is an issue (and perhaps that is firewall related). now hopefully everything is still working Thanks for the suggestion.

I'm trying to upgrade from v.5.0.16 to v.5.0.16(c) because my insteon heartbeats are not working. I have a isy994 zw and am using the udi_oadr_5.0.16C.zip ...I get to 96% complete and then receive a ”Upgrade Failed: Failed uploading file (reported written size is invalid)” I've rebooted the isy, I've cycled power on the isy, I've re-downloaded the firmware image...I've tried updating 5x times...I'm stuck. What does this message indicate, and how do I fix the issue?

Perhaps you've determined a solution by now, but if not could I suggest using a ping/nmap/arp-scan followed by an "arp -a | grep <macid>"? ...assuming you know the mac-id (or mac-id range/manufacturer) you can probably find the IP address (and hostname if router supports it)...obviously you have to be able to scan the subnet that is used (and if you can't, not knowing the ip address won't help you anyhow). I've used this to "find" devices sitting on a network after they have dhcp'd in. The ping scan/arp is easy in Linux, and apparently achievable in Windows , probably would need to wrap in simple script of some type to allow easy usage/redirection. The arp (mac-id presentation) only works on the subnet of the host (to my knowledge)...so definite limitations. Also, my tp-link smart switches are able to be located on a different isolated (vlan) subnet by their switch management tool...so I may have to break out wireshark and see how that is happening (possibly they are "phoning home"...because I don't know how else they are achieving this). (update...the app is doing a broadcast UDP query, the switches doing a broadcast UDP reply...I guess because the broadcast was to 255.255.255.255 pfSense is forwarding to all my vlan subnets)

Ok...took a bit of playing, but figured this out. You cannot directly control the IOLINC and have the modes b/c work (as described above, they behave like mode a). You must create a scene (even if just the 2450...and implicitly including the isy994i) and control the scene...doing this, everything works as expected.

I've just received my 2450 v.41 IOLINC...I'm wondering if the option programming procedure may have changed and these no longer are configuring correctly. The only modes of operation that seem correct are "Latching" and "Momentary A". "Momentary B" and "Momentary C" behave the same as "Momentary A" The IOLINC will do nothing with an "OFF" command (so "B" not working), and "ON" commands always yield yield a momentary output (regardless of the state of the input...so "C" not working). .ie "B" and "C" options seem to yield "A" behavior. I've not tried manual setting the modes (as that is why I bought an ISY )...but may try if nobody has an idea. I'm also unclear what the statement "If it is Linked while On it will respond to On. If it is Linked while Off it will respond to Off" means...mine always responds to the "ON". Does it mean the state of input when linking? State of output when linking?