Bumbershoot

This means that process 17542 is still running. The process might be hung, or just busy. If it continues, you might consider giving your machine an orderly shutdown/restart -- I wouldn't pull the plug on it: sudo shutdown -r now

For now, this update is for Polisy only. For the ISY994i, the last version of firmware available is the version you're on, 5.3.4.

I'm in a similar boat as @gviliunas, @mwaite75 and @csteenwyk. The exclude completes quickly, but the include times out in the interview. I cold booted the Polisy, so there might be something missing from file early in the startup. EDIT: I'm going to do what I probably should, and that's factory reset the Z-Wave dongle and rebuild my Z-Wave network. It's not so big and cumbersome that it'll take that long, and I'm interested to see how it looks with a fresh start. Once in a while it's good to let my OCD impulses run... 😁 MYLOG.TXT

A comment I'll make is that switching from Polisy to eisy won't likely result in a dramatic performance improvement in the IoX software. As it is, even when IoX is busily chugging away, the Polisy CPU/RAM combination is basically loafing. I suspect that big improvements in performance will likely happen as the IoX software changes, not so much as the hardware it runs on improves. That said, faster CPU's and more RAM are always better. last pid: 60652; load averages: 0.48, 0.42, 0.36 up 3+20:00:34 07:16:42 47 processes: 1 running, 46 sleeping CPU: 0.6% user, 0.0% nice, 0.5% system, 0.2% interrupt, 98.8% idle Mem: 161M Active, 598M Inact, 96M Laundry, 2797M Wired, 267M Free ARC: 2259M Total, 1359M MFU, 657M MRU, 28M Header, 169M Other 1854M Compressed, 2190M Uncompressed, 1.18:1 Ratio Swap: 4093M Total, 4093M Free

Sorry, I can't answer any of these with authority. I can guess, though 😀 Yes I can't imagine why not, as data throughput likely isn't an issue I'd think so, yes See 3 above Yes Remotely locating the ZMatter dongle in a high, central location (away from your Polisy) might work very well. I'm considering this, as I'd like to have my Polisy in an accessible location, but I could put the dongle in the attic. I doubt that the data rates from the field to your Polisy through the dongle would be sufficient to swamp a modern USB device. The only advantage I see is that inserted in the Polisy, it's out of harms way. BUT, check with UDI first!

I'll jump in here. I don't know of any compelling reason for UDI to officially support HA on their eisy, but who knows, maybe they will. Barring that, you can install HA on a FreeBSD box, and I'm sure it will run beautifully. Here are some instructions to get HA running on FreeBSD: https://www.sysadsim.com/2021/03/running-home-assistant-on-freebsd.html Unless you're reasonably comfortable as a *NIX sysadmin, then I'd stick with the Yellow Box. Even if you get HA running using the instructions above, you'll still have to manage the software onboard your eisy, and that management will very likely involve the command line interface. If that doesn't sound appealing, then the Yellow Box might be way, way easier to manage.

I think you just need to get one of these: https://www.universal-devices.com/product/zmatter-usb-enclosure/

Right you are! I never bothered to look, so thanks for this tip.

Looks like this vulnerability was corrected in the repositories last month, so it's very likely your Polisy OS is fixed if you've clicked on the "Upgrade Packages" button after the correction date below of 2022-11-29: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-22:15.ping Security Advisory The FreeBSD Project Topic: Stack overflow in ping(8) Category: core Module: ping Announced: 2022-11-29 Credits: Tom Jones Affects: All supported versions of FreeBSD. Corrected: 2022-11-29 22:56:33 UTC (stable/13, 13.1-STABLE) 2022-11-29 23:00:43 UTC (releng/13.1, 13.1-RELEASE-p5) 2022-11-29 22:57:16 UTC (stable/12, 12.4-STABLE) 2022-11-29 23:19:09 UTC (releng/12.4, 12.4-RC2-p2) 2022-11-29 23:16:17 UTC (releng/12.3, 12.3-RELEASE-p10) CVE Name: CVE-2022-23093 EDIT: For what it's worth, from a quick look at the files on my Polisy at '/usr/local/etc/pkg/repos', it appears that my Polisy is getting updated files from both the FreeBSD project and UDI specific repos. My guess is that UDI maintains a FreeBSD mirror as well as having a repository for their own software. This should mean that any updated packages from the FreeBSD maintainers should be passed along to Polisy users in relatively short order, provided users update their machines.

You need a DB9 <--> RJ45 cable, such as this: https://smartenit.com/shop/plm-serial-cable/ One of these cables shipped in the box that your PLM came in. The ports on the back of the polisy are for ethernet communications, not serial.

The current practice for updating packages is to click on the "Upgrade Packages" in the AC (screenshot):

Looks like you're not the only one to notice that today:

Send them an email: support@universal-devices.com

I have a similar setup, and nothing Z-Wave is "mission critical". I put the ZMatter card in my Polisy yesterday (along with leaving in the Zooz stick) and discovered that I couldn't communicate with Z-Wave devices at all. I don't know what to attribute that to other than having two Z-Wave controllers, both competing for the same RF, that the ZMatter card is stomping all over the Zooz stick. I deselected Z-Wave Support in the Configuration tab, restarted IoX and all is well again, minus Z-Wave. In my installation, the ZMatter card and the Zooz stick don't seem to get along... I'll probably wait until Tuesday for the migration utility, and if it's not available, then I'll remove the Zooz stick, re-enable Z-Wave Support, and exclude/include the devices with the ZMatter card. It'll be some pain to do it that way, but with a Polisy Pro, I can use WiFi and move it close to devices that don't support NWI.

It's simply another nice little box running FreeBSD. The value is in what UDI builds on top of the OS. FreeBSD is a rock solid UNIX variant OS, and there are basically no license restrictions to it's use, may be why UDI chose to use it, other than *did I mention* it's rock solid. Way back when, in my professional life, I ran a few FreeBSD machines in mission critical applications, and I might reboot them once a year, whether they needed it or not. It was always a panic to find the root password for those machines every year... Here's a rabbit hole: https://en.wikipedia.org/wiki/Berkeley_Software_Distribution

Polisy is running ZFS, a 128 bit filesystem. [admin@polisy ~]$ dmesg | grep ZFS ZFS filesystem version: 5 Windows isn't going to know anything about a ZFS file system, natively.

@simplextech, I don't know if this is a node server issue or a general PG3 issue, but restarting the node server does not perform the upgrade from v1.0.5 to v1.0.6. Several restarts of the node server, and no joy...

I can't really answer the first part of your question with any authority, as I have my own PWS (WeatherFlow), but prior to getting that, I used Climacell node server and found it very useful at my location. Regarding using substitution variables in your notification: The values that appear in your notification can be derived from the Polyglot installation. My WeatherFlow node server is installed in slot 12 (which is why you see .../node012... in the URL below). I use the REST interface to look up the values, and I do this using this URL in a browser: http://192.168.1.19:8080/rest/nodes/n012_forecast_0 This returns XML that looks like this: <nodeInfo> <node flag="0" nodeDefId="forecast"> <address>n012_forecast_0</address> <name>Forecast 0</name> <family instance="12">10</family> <parent type="1">n012_controller</parent> <type>0.0.0.0</type> <enabled>true</enabled> <deviceClass>0</deviceClass> <wattage>0</wattage> <dcPeriod>0</dcPeriod> <startDelay>0</startDelay> <endDelay>0</endDelay> <pnode>n012_controller</pnode> </node> <properties> <property id="GV0" value="32" formatted="32°F" uom="17" prec="1"/> <property id="GV1" value="212" formatted="21.2°F" uom="17" prec="1"/> <property id="GV13" value="4" formatted="Snow Possible" uom="25"/> <property id="POP" value="30" formatted="30%" uom="51"/> <property id="ST" value="0" formatted="Sunday" uom="75"/> </properties> </nodeInfo> Just match up the "property id" with the "value" you're looking for, and it's pretty easy to figure out. It's pretty easy to figure out the <address>n012_forecast_0</address> you want by looking at the AC (screenshot). EDIT: See the wiki on Substitution Variables here: https://wiki.universal-devices.com/index.php?title=ISY-994i_Series:EMail_and_Networking_Substitution_Variables

Here’s a good place to buy in the US: https://www.supplyhouse.com/Sensors-14422000

The VenstarCT node server has a default shortpoll value of 20 seconds, though that’s user configurable. I believe the temperature granularity is one degree.

I only have one stat, but I have sensors in remote parts of the house. There are both wired and wireless (WiFi) sensors available. There is a utility from Venstar that you use to provision the wireless sensors (don’t know about the wired ones). The wireless sensors can be wall mounted, though they’re kinda big. See if they meet the WAF before purchasing. I set them up as fixed IP addresses (IP reservations) and with Lithium batteries, they seem to run forever. I just put them on shelves where the Mrs. doesn’t notice them, and she’s never been more comfortable.

It might be possible to do something interesting. If you have a window sensor that indicates the window is open, then set mode to “Off” until the remote sensor drops below “X”. That ought to work.

I don’t see anything in the API to suggest that functionality you’re looking for is available outside of the app or the Skyport website (which seems odd — maybe that functionality is undocumented). You do have sensor data available to the ISY through the node server, so you could possibly write some programs that manage setpoints based on individual sensor data of your choosing.

I may have used too much poetic license by saying “instantaneous”. Some values are updated in the ISY using the “short poll” value in the node server. I believe the default is 20 seconds, though you can set it to suit your needs.

Venstar ColorTouch T5900 thermostats provide a local API and there is a very good node server to control them from your ISY. There is a cloud based app to control them as well, but connecting to your ISY is entirely on your local WiFi network, and instantaneous, as far as I can tell. Heat pumps are supported. I believe the temperature granularity is one degree, and I use two remote temperature sensors to provide input. The sensors are supported by the node server. https://files.venstar.com/thermostats/colortouch/documents/T5900_manual_rev4.pdf