MWareman

This has let me down a rabbithole now.. I have been having trouble witht he BIOS update - it just seemed to fail from the GUI. Of course - I noticed the 'update.bios' command in the script.. [admin@polisy ~]$ sudo /usr/local/etc/udx.d/static/udxops.sh update.bios executing from /usr/local/etc/udx.d/static Sun Oct 2 18:28:03 CDT 2022|/usr/local/etc/udx.d/static/udxops.sh: starting bios update Sun Oct 2 18:28:04 CDT 2022|/usr/local/etc/udx.d/static/udxops.sh: bios mfr: Universal Devices Sun Oct 2 18:28:04 CDT 2022|/usr/local/etc/udx.d/static/udxops.sh: bios product: Polisy Sun Oct 2 18:28:04 CDT 2022|/usr/local/etc/udx.d/static/udxops.sh: bios ver: 1.0.0 Sun Oct 2 18:28:04 CDT 2022|/usr/local/etc/udx.d/static/udxops.sh: bios version 100 is old and needs to be upgraded flashrom on FreeBSD 13.1-RELEASE-p2 (amd64) flashrom is free software, get the source code at https://flashrom.org Using default programmer "internal" with arguments "". Using clock_gettime for delay loops (clk_id: 4, resolution: 2ns). coreboot table found at 0xcfec5000. Found chipset "AMD FCH". Enabling flash write... OK. Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) mapped at physical address 0x00000000ff800000. Using regions: "RW_SECTION_A", "RW_SECTION_B", "PSPDIR". Reading old flash chip contents... done. Erasing and writing flash chip... FAILED at 0x00030000! Expected=0xff, Found=0x24, failed byte count from 0x00030000-0x00030fff: 0xd d2 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00030000! Expected=0xff, Found=0x24, failed byte count from 0x00030000-0x00037fff: 0x7c92 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00030000! Expected=0xff, Found=0x24, failed byte count from 0x00030000-0x0003ffff: 0xf708 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x2f, failed byte count from 0x00000000-0x007fffff: 0x555677 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x2f, failed byte count from 0x00000000-0x007fffff: 0x555677 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. Looking for another erase function. Looking for another erase function. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Your flash chip is in an unknown state. Get help on IRC at chat.freenode.net (channel #flashrom) or mail flashrom@flashrom.org with the subject "FAILED: <your board name>"! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! Sun Oct 2 18:29:37 CDT 2022|/usr/local/etc/udx.d/static/udxops.sh: bios update ... rebooting POLISY then rebooted - and (fortunately) it came back. Seems the BIOS update process is failing on my POLISY and thru the CLI there is at least some detail as to why. How would I go about addressing this? Thank you!

Thank you!

I edited the unifi_poly.py to comment out the line (line 15) - and the poly then started fine. I'm not sure if the library is used anywhere - but it seems it may not even be needed at first glance.

I guess one question is - why is the pushover module needed for this poly? Seems unnecessary for the purpose. I did try installing the module: pip install pushover-python I get the same error - even though the install appears to have been successful.

I know this poly was working in thee past - but in one of the upgrades something obviously occurred. I have tried restarting, but every time I get this error (and it stops). 2022-10-01 14:10:35,429 MainThread udi_interface INFO polylogger:set_basic_config: set_basic_config: enable=True level=30 2022-10-01 14:10:38,326 MainThread udi_interface INFO __init__:<module>: UDI Python Interface for Polyglot version 3 3.0.47 Starting... 2022-10-01 14:10:38,331 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2022-10-01 14:10:38,332 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/{UUDID}_15/./unifi_poly.py", line 15, in <module> 2022-10-01 14:10:38,334 MainThread udi_interface ERROR udi_interface:write: from pushover import init, Client 2022-10-01 14:10:38,335 MainThread udi_interface ERROR udi_interface:write: ModuleNotFoundError 2022-10-01 14:10:38,336 MainThread udi_interface ERROR udi_interface:write: : 2022-10-01 14:10:38,337 MainThread udi_interface ERROR udi_interface:write: No module named 'pushover'

That makes sense now. It was odd at the time because 'pkg update' updated something that had a dependancy on a newer library that had not yet been updated. Is there a cli way of (for instance) going from 13.0 to 13.1 safely?

Good to know - thank you!

Update: *MUCH* better. Polys all started. Problem looks solved. Still don't know why the admin console update did things beyond the pkg package manager. Thank you @bpwwerfor the solution!

Interesting. I had not been doing this - rather 'pkg update && pkg upgrade' at the cli. Opening the admin console - I hit this button and immediately the admin console (and finder) closed. As if it crashed. Thru SSH - I was watching /var/log/messages and nothing. After a few mins - I started the admin console again - and all of a sudden I see events like this in /var/log/messages: Sep 25 13:38:04 polisy pkg[4779]: FreeBSD-runtime-13.0p11 deinstalled Sep 25 13:38:08 polisy pkg[4779]: FreeBSD-utilities-13.0p11 deinstalled Sep 25 13:38:09 polisy pkg[4779]: FreeBSD-libbsdxml-13.0p11 deinstalled Sep 25 13:38:09 polisy pkg[4779]: FreeBSD-libregex-13.0p11 deinstalled Sep 25 13:38:09 polisy pkg[4779]: FreeBSD-libregex-dev-13.0p11 deinstalled Sep 25 13:38:09 polisy pkg[4779]: FreeBSD-utilities-dev-13.0p11 deinstalled Sep 25 13:38:09 polisy pkg[4779]: FreeBSD-libbsdxml-dev-13.0p11 deinstalled Sep 25 13:38:14 polisy pkg[4779]: FreeBSD-runtime-13.1p2 installed Sep 25 13:38:14 polisy pkg[4779]: FreeBSD-libmagic-13.0p11 deinstalled Sep 25 13:38:15 polisy pkg[4779]: FreeBSD-runtime-dev-13.0p11 deinstalled Sep 25 13:38:15 polisy pkg[4779]: FreeBSD-rc-13.0p11 deinstalled Sep 25 13:38:15 polisy pkg[4779]: FreeBSD-liblzma-13.0p11 deinstalled Sep 25 13:38:15 polisy pkg[4779]: FreeBSD-libthread_db upgraded: 13.0p11 -> 13.1p2 Sep 25 13:38:15 polisy pkg[4779]: FreeBSD-libbsm upgraded: 13.0p11 -> 13.1p2 Sep 25 13:38:15 polisy pkg[4779]: FreeBSD-libsmb upgraded: 13.0p11 -> 13.1p2 Sep 25 13:38:15 polisy pkg[4779]: FreeBSD-libbsdstat upgraded: 13.0p11 -> 13.1p2 Sep 25 13:38:15 polisy pkg[4779]: FreeBSD-libucl upgraded: 13.0p11 -> 13.1p2 Sep 25 13:38:16 polisy pkg[4779]: FreeBSD-bluetooth upgraded: 13.0p11 -> 13.1p2 Sep 25 13:38:16 polisy pkg[4779]: FreeBSD-libvgl upgraded: 13.0p11 -> 13.1p2 Sep 25 13:38:16 polisy pkg[4779]: FreeBSD-libcuse upgraded: 13.0p11 -> 13.1p2 Sep 25 13:38:16 polisy pkg[4779]: FreeBSD-libarchive upgraded: 13.0p11 -> 13.1p2 Sep 25 13:38:19 polisy pkg[4779]: FreeBSD-openssl-13.1p2 installed Sep 25 13:38:19 polisy pkg[4779]: FreeBSD-libmagic-13.1p2 installed ..... I suspect these are the dependencies being spoke of (at some point I did earlier see a 'running kernel mismatch' error). At the end of the upgrades - Polisy auto-rebooted: Sep 25 13:40:02 polisy reboot[5956]: rebooted by admin

No updates yet: Should I be expecting to see something thru the 'pkg update && pkg upgrade' process?

During the last 'pkg upgrade' - the following got updated: Sep 23 20:33:05 polisy pkg[2395]: python39 upgraded: 3.9.13 -> 3.9.14 Since then, I see this error when most PG3 Polys start (as well as having similar issues identified in this thread - high latency on zwave devices for example): 9/25/2022, 11:06:13 [pg3] error: [LiFX(6)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found I have a feeling that a missing Python dependency like this might affect a lot more than just polys running. libpython3.9.so.1.0 was updated from the UDI package server - but libc.so.7 should likely have also been updated to be conformant is it does not appear this was the case from the logs.

More from the log - during a reboot: 9/25/2022, 11:06:13 [pg3] error: [Sonos(14)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] debug: [Sonos(14)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:13 [pg3] info: startNs:: Sonos starting polls 9/25/2022, 11:06:13 [pg3] info: Starting Node server Info timer 0 9/25/2022, 11:06:13 [pg3] error: [Timedata(9)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] error: [ELK(10)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] error: [LiFX(6)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] error: [Sun(11)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] error: [Ping(8)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] error: [Plex-WebHook(12)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] error: [WirelessTag(4)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] error: [NOAA(5)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] error: [UnifiPresence(15)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] error: [MQTT(13)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] error: [WeatherFlow(7)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/25/2022, 11:06:13 [pg3] debug: [Timedata(9)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:13 [pg3] debug: [ELK(10)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:13 [pg3] debug: [LiFX(6)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:13 [pg3] debug: [Sun(11)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:13 [pg3] debug: [Ping(8)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:13 [pg3] debug: [Plex-WebHook(12)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:13 [pg3] debug: [WirelessTag(4)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:13 [pg3] debug: [NOAA(5)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:14 [pg3] debug: [UnifiPresence(15)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:14 [pg3] debug: [MQTT(13)] :: Exit cause code: 1 - signal: null 9/25/2022, 11:06:14 [pg3] debug: [WeatherFlow(7)] :: Exit cause code: 1 - signal: null Looking at everything that updated a couple of days ago: I tried reverting pg3 and udx - but this did not resolve the issue at all. I have a feeling there is a missing dependency in the updated python39.

Maybe a bug in FreeBSD? Or the update process? https://forums.freebsd.org/threads/version-fbsd_1-7-required-by-usr-local-lib-libpython3-9-so-1-0.86449/ Not sure if Polisy is using jails - so don't want to 'try' the workaround without guidance.

Issuing a 'Stop' 'Start' or 'Restart' does not appear to do anything in the GUI. Bulbs that were working are not working. This appears to affect all node servers on PG3... When starting LiFX - I see this in the debug log: 9/24/2022, 11:12:18 [pg3] info: startNs:: LiFX 9/24/2022, 11:12:18 [pg3] info: startNs:: LiFX is valid 9/24/2022, 11:12:18 [pg3] debug: checkLicense:: LiFX Getting node server store entry 9/24/2022, 11:12:18 [pg3] debug: checkLicense:: LiFX Getting node server purchase record 9/24/2022, 11:12:18 [pg3] debug: Getting status for LiFX {MAC} {GUID} 9/24/2022, 11:12:18 [pg3] info: checkLicense:: LiFX No license found for Free node server. 9/24/2022, 11:12:18 [pg3] info: startNs:: LiFX finished update check 9/24/2022, 11:12:18 [pg3] info: [LiFX(6)] :: Starting Node server - Version 2.1.26 9/24/2022, 11:12:18 [pg3] info: startNs:: LiFX updating database (enabled, timestarted) 9/24/2022, 11:12:18 [pg3] error: [LiFX(6)] :: STDERR: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 9/24/2022, 11:12:18 [pg3] debug: [LiFX(6)] :: Exit cause code: 1 - signal: null Seems a library is missing (!). Not sure how that happened. Any ideas to resolve? It was working prior to the last 'pkg update && pkg upgrade' where the latest udx (among some other items) were updated.

This is what is working for me as an ISY NR (I have 8 of these now - 16 total NRs on on and one off per device) Use TCP, to port 9999 and mode 'Binary'. Set the IP. Use the body applicable: ON: 0;0;0;42;208;242;129;248;139;255;154;247;213;239;148;182;197;160;212;139;249;156;240;145;232;183;196;176;209;165;192;226;216;163;129;242;134;231;147;246;212;238;222;163;222;163 OFF: 0;0;0;42;208;242;129;248;139;255;154;247;213;239;148;182;197;160;212;139;249;156;240;145;232;183;196;176;209;165;192;226;216;163;129;242;134;231;147;246;212;238;223;162;223;162 Michael.

I use a USB 3.0 extension cable (to get the radio devices outside of my 19" rack enclosure) - and a powered 3.0 hub at the end to plug the zwave device in. I'm thinking about moving from the USB PLM to the wireless USB PLM (2448A7) as well - to reduce the effect of power disturbances on the ability to damage the PLM (I managed to get one before they disappeared from stock everywhere).

AFAIK - It's not full featured quite yet. I extensively use the ISY to send spoken announcements thru the Elk's speaker for certain events - and I cannot find that function yet in the nodeserver. Do we know if this is planned? Certainly - the old firmware native premium Elk plugin supported this. Perhaps the newer PG3 version supports it - I don't know yet as I'm running the Elk nodeserver on PG2 until I know for sure the for-cost PG3 version is fully feature complete. Michael.

I do hope this can be changed. I don't mine the queue itself - but the substitution needs to occur when the event is queued rather than when it's processed.

Michel, I'm having the problem with most programs using this NR - but it manifests slightly differently on differing devices. I'm really hesitant to go down the road of recreating all the NRs to test. I've done a test though by changing the main NR to a static string. The symptom remains (It's not to do with the substitution). My 'Family Room Floor' light is not triggering the NR at all - and it's the same NR. Here is where I tested: I modified 'Pushover - Notify Light status' to send a fixed string (no substitutions). I modified 'Broadcast Device Status' to send a fixed string (no substitutions). I manually tested both fixed-string NRs - and both worked fine. When I switched the light - the status in the admin console changed, the statue and integer variables changed (so I know the program triggered) - but neither of the NRs fired at all. If I 'Run Then' the program - the NR does not fire either. Michael.

A bit more experimentation. The program is triggering (I have some variable assignments immediately following the network resource - and these are being updated). However - the NR is never run. So far - I have not found anything in the logs. This is a multicast NR just to broadcast the device status. I tried changing it to a unicast udp with the same result. A manual 'test' of the NR works though. This is something about how it's triggered in a program and the fact that the NR contains '#' to represent the triggering device.

Thank you. At what point are the substitutions performed? Is it as or before the event is queued - or as events are pulled off the queue and delivered? IMO as long as substitutions are performed when the events are queued it really shouldn't matter. I'm trying to determine if the # in a substitution is reliable - or could be a different device ID by the time an event comes out of the queue. My main current issue is that I'm having many, many other issues seemingly caused by status not updating. I have this: The 'Pushover - Notify Light Status' contains this payload (as the 'message' for a Pushover message): ${sys.node.#.name}+-+(${sys.node.#.addr})+${sys.node.#.ST} I get a message correctly substituted when I turn the light off - but not when turning it on (should be triggering on 'Status is not Off'). No event is delivered at all. This used to work to trigger every time the status changed at all (by on, off, dimming, remote or local control). I have tried a 'Restore Device' (just in case the link table got corrupted) but it's behaving the same. Did something change here - or is there a better way to have a program trigger every time the status updates? (I cannot use 'switched' as sometimes the light is adjusted by API - and I need the program to trigger when this occurs as well).

Another odd caveat - may be related. Insteon dimmer switch. I have this program triggering condition: This used to trigger whenever the status changes. Now - it's only triggering when the status goes 'Off'.

Seems to confirm my symptoms. Devices do not appear to have their status updated at all unless manually queried. In my case this does appear to be affecting zwave as well as Insteon. For instance, I turned 'Off' a HomeSeer HS-WD100+ device. I got 'DON 0' in the log - but the status stayed at '100%'. Right/click and 'Query' - the status then changes to 0%.

The issue with the program triggering appears related to something core. If I manually query a device to get a statues - then the program triggers. It just does not trigger when a device updates. It seems the ISY/Polisy is not processing organic status updates properly. @sjenkins - I think you are having the same issue with your PLM communication.

I am noticing that with this version most of my programs are not triggering on the state change of Insteon nodes (at least): This does not trigger anymore (used to). This still does for local device changes: Since I need most programs to trigger for both remote and local changes to the device - this is problematic.