shbatm

Looks like the issue is with libbson being updated in the upgrade.polisy script, my fix wasn't as simple... Note: this is not advice from UDI. Follow at your own risk. This is the output of the update script. The following 2 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: mongo-c-driver: 1.8.1 Installed packages to be UPGRADED: libbson: 1.8.1 -> 1.23.2 [FreeBSD] Number of packages to be removed: 1 Number of packages to be upgraded: 1 I updated "/usr/local/etc/pkg/repos/FreeBSD.conf" to the following (change "latest" to "quarterly") FreeBSD: { url: "https://pkg.FreeBSD.org/${ABI}/quarterly", enabled: yes, priority: 1 } Then ran: "sudo pkg upgrade -f mongo-c-driver" Which downgraded libbson back to 1.8.1 The following 2 package(s) will be affected (of 0 checked): Installed packages to be DOWNGRADED: libbson: 1.23.2 -> 1.8.1 [FreeBSD] Installed packages to be REINSTALLED: mongo-c-driver-1.8.1 [udi] Number of packages to be reinstalled: 1 Number of packages to be downgraded: 1 After that, all services were back.

*removed, see post below*

These 'claim' they are running on my polisy, but I don't have any isy ports open (sockstat), no isy log files have been updated since I mashed the button last night, and when I try and manually run the ISY binary it's complaining about a missing library object referenced online with the Mongo-c-driver.

Running into the same issue. Also have a ticket open. Looks like there's issues with the mongo-c-driver build on FreeBSD 13, not sure if that's still required or not (but restarting the udx service manually complains about it not being installed). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269301 https://portsfallout.com/fallout?port=devel%2Fmongo-c-driver%24

@MrBill Let know if you're able to get the Polisy working with Home Assistant--if everything is the same for the REST and Websocket interfaces like @Michel Kohanim mentioned, then I don't think there should be any changes needed for PyISY connecting for Home Assistant. Like I mentioned in our other chat--I've had some major life changes recently so I haven't been able to do much with my Polisy to test anything, but I do have the hardware if there is anything I need to test.

Versions v2.1.2 and v3.0.1 have been released with the corrected unsubscribe code. @Javi would you mind also checking the reconnect strings (same file further down) to make sure those are correct?

For the Avery 18667 I set the button face up and use the overhang of the labels to position it, then flip the button over and trim the excess with an xacto knife.

I used acetone a few years ago when I did this Avery Label method--works pretty well if you just use a bit on a cotton swab and take a few swipes then repeat with a swab that has water; don't over do it or you'll pull the glossy finish off too much. EDIT: I can't find the original link, but if anyone is interested in the label method: That was what I did a few years ago, and they stood up to a lot of use. Ready to graduate to the lasers now though. Thanks to everyone who's posted their experience so far; will be trying this soon.

There is no way to set the scene parameters for a specific device without adding the device to the scene, which jumps to a default of 0.1/100. To recreate: 1) Set the OL/RR of a device and 2) add it to a new scene by itself as a controller. What you may be referring to is when you add a device as a controller to an existing scene, in which case, yes--the new controller will inherit the scene parameters for the other devices in the scene, but it will still overwrite it's own OL/RR to 0.1/100.

@blueman2 and @Michel Kohanim thanks for the feedback on this being intentional -- I guess I was thinking about it backwards -- I set the ramp rate and on levels for the device to what I wanted and when I decide to add it as a controller for a scene I was expecting the new scene to default to the device's OL/RR settings, not reset them to 0.1/100%. This brings up a more general question that I've run into the past few days trying to re-link everything: Why does a new scene created in the ISY not default to the OL/RR of each device, but instead force everything to 0.1/100% and force the user to go reset it for all the controllers and the ISY scene? Is there a design rational behind this as well? I know the "apply to all devices" was removed in 5.x to accommodate the different device types with node servers--but this coupled with having to reset the OL and RR for each device under each controller back to what I set the device up as originally has been a PITA for larger scenes (venting, sorry... admittedly this has been exacerbated by my current situation of re-installing and relinking 50+ Insteon devices in one shot for a new house--/rant). Thanks as always for the awesome work you guys do!

Just upgraded to 5.2.0 (RC3) from 5.0.16C and am in the process of updating all my devices and scenes for the my new home. I'm having an issue where the Insteon On Levels and Ramp Rates are being reset to 100% in 0.1s whenever a device is added to a new scene. To recreate: Set a device's On Level to 50%, Ramp Rate to 0.5s in the Admin Console. Create a new scene and add the device to it EDIT: as a controller. Go back to the device, Ramp Rate is back to 0.1s and On Level is back to 100%. Also tried querying the device to see if it was a bad value in the Admin Console, but same result. Confirmed at the physical device, the ramp rate and on level settings are lost. Seems to apply to both KeypadLincs and SwitchLinc Dimmers. Is anyone else seeing this?

I think this is the link you were looking for: Made the repair to mine 5 years ago, been **knocks on wood** working since.

Sorry if I was confusing--I was saying that even though my sensor setup is reversed and yours is not, I saw the same thing with the 3am query--except my sensor would turn OFF (normally ON with door closed). Simply calling a program that uses that sensor as the IF clause would get it to show up back "on" correctly. I didn't realize you had actually had the Garage Door go open! I like the hard-switch idea. Just curious, what controllers do you have tied to the opener--did something command the relay on when the sensor flipped, or did the relay flip by itself too? (Another issue I've had is the relay node, even though it's set up as only momentary, will stay "ON" and I have to have an ISY program turn it OFF after 5 seconds--may all be caused by noise-I just went the route of @jec6613 and bought a FilterLinc @ 50% off).

I've had this behavior for years, I always just thought it was a strange quirk. In my 3am query program I added a "Wait 3 Seconds" then "Run If" for my Garage Sensor change program (the program that updates/reverses my KeypadLincs. The "re-check" of the sensor in the if statement is usually enough to correct the sensor status. Of all the $$$ and time I've spent on Insteon and SmartHome.com -- This is the first I've ever heard of a FilterLinc. Thanks for the suggestion!