Bumbershoot

That's exactly my plan as well. I have 11 irrigation zones of various plant/soil types, but with record cold temperatures this month in the Pacific NW, I haven't had a chance to run the irrigation system much. Thanks for the reply.

I haven't paid Flume a single ¢ since I bought the thing, and the API has always been accessible. The accuracy seems astonishing to me as well, as the reported monthly water usage have been only a couple of gallons different from what my utility sees, and this is without device calibration. I'm impressed with this device, so far, and it works well with the Flume Node server. @hart2hart, are you getting value from the subscription?

I found the IPv4 Networking settings in PG2 to be a bit confusing. IIRC, you have to make certain that the WiFi interface in actually turned on. Just removing the ethernet cable and restarting the Polisy won't do it. In any event, I got it to work when I needed it. Other than that, I've switched back to using a wired network...

The command 'ifconfig -a' will get you the MAC address of the interface, if it's active, which you can then look up in your router tables once it's connected. You might be able to copy that and make a static DHCP reservation in your router before restarting the Polisy to use the interface, as well. I just looked it up once Polisy WiFi was connected. YMMV.

You can always use the 'netstat' command, but it won't show an inactive interface without in IP address. In my router, it showed up as 'POLISY' if I recall. The interface isn't active, so I can't check.

It's in the PG2 interface. It has to be coming to PG3, but I guess it's not there yet.

WiFi does work. I used it when I repositioned my Polisy to get it closer to some older Z-Wave devices for exclusion/inclusion.

The only 'gotcha' with doing this is that if you've already migrated your Insteon devices, you'll get lots of pop-up notices in the AC about unavailable Insteon devices unless you also plug in a PLM (I used a spare) or turn off Insteon support in the AC prior to the restart. Not a big deal, but something to note.

I did find an advantage of having a Pro when I migrated. I had some Z-Wave devices in difficult locations that I could not exclude or include from the default Polisy location, and I didn't have a long enough ethernet cable to move the Polisy closer. The solution was to enable WiFi on the Polisy, and move the Polisy close to the Z-Wave devices to enable exclusion/inclusion. These devices are older devices such as Schlage locks, etc. Worked like a charm.

EDIT: This isn't a fatal error! The Node server is running as designed, as far as I can tell. I've deleted the PG2 version, and installed the PG3 version, but it errors on startup: 2022-04-18 07:18:46,691 MainThread udi_interface.interface INFO interface:addNode: Adding node WirelessTagsController(wtcontroller) [None] 2022-04-18 07:18:46,694 MainThread udi_interface.interface INFO interface:setController: Using node "wtcontroller", driver "ST" for connection status. 2022-04-18 07:18:46,884 Thread-6 udi_interface ERROR Controller:handler_nsdata: NSDATA is a string? Are you running a local copy? data=undefined Thanks for whatever insight you can give, or, I can just ignore it...

I have three different types that I've been testing, and while all good, the best for me in general lighting applications has been the Zooz Zen7x series. The ergonomics of this switch are good, and they respond very quickly, especially with a series 700 controller. Other switches I've used successfully are the GE/Jasco Embrighten (which are Z-Wave+, not series 700) switches/dimmers/motion sensors/fan switches (the switches/dimmers with the built-in motion sensors solve several problems for me), and Homeseer switches (to be fair I haven't installed their HS WX-300 yet, but the previous version is very good, and the status RGB LEDs can be useful in some situations). I'm still relying on Insteon for most of my lighting, so I haven't done anything fancy with the Z-Wave switches -- I just control them with ISY programs, but they've all been reliable, and I could (and do) live with any of them.

This may not be related to your issue or the Node server, but if you have a mesh WiFi network, then some Sonos installations can have problems staying continuously connected to WiFi. Two solutions have worked to solve this issue in the couple of networks that I've had to deal with: 1) connect one Sonos speaker to the network with an ethernet cable instead of WiFi, or 2) add a Sonos Boost to the network. If the problem continues and you have a mesh WiFi setup, this may solve your issue.

It won't hurt me, as production is on PG2, and will be for a while yet. I like the sounds of what this update will provide, however. I'll probably install the notification Node server as well due to the Short Custom Content functionality.

Thanks, that works...

Thanks. I set the log level to "Info" and it's chugging along just fine now.

This appears to be happening with other node servers as well, but with the latest PG3 3.0.54 update, I'm getting these errors in the log: 2022-03-29 07:06:09,912 MQTT udi_interface.interface INFO interface:_message: Successfully set key = notices 2022-03-29 07:06:10,081 Command udi_interface ERROR udi_interface:write: Exception in thread 2022-03-29 07:06:10,082 Command udi_interface ERROR udi_interface:write: Command 2022-03-29 07:06:10,082 Command udi_interface ERROR udi_interface:write: : 2022-03-29 07:06:10,083 Command udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2022-03-29 07:06:10,084 Command udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/threading.py", line 932, in _bootstrap_inner 2022-03-29 07:06:10,088 Command udi_interface ERROR udi_interface:write: self.run() 2022-03-29 07:06:10,089 Command udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/threading.py", line 870, in run 2022-03-29 07:06:10,093 Command udi_interface ERROR udi_interface:write: self._target(*self._args, **self._kwargs) 2022-03-29 07:06:10,094 Command udi_interface ERROR udi_interface:write: File "/var/polyglot/.local/lib/python3.8/site-packages/udi_interface/interface.py", line 678, in _parseInput 2022-03-29 07:06:10,098 Command udi_interface ERROR udi_interface:write: self._handleInput(key, input[key], None) 2022-03-29 07:06:10,099 Command udi_interface ERROR udi_interface:write: File "/var/polyglot/.local/lib/python3.8/site-packages/udi_interface/interface.py", line 684, in _handleInput 2022-03-29 07:06:10,103 Command udi_interface ERROR udi_interface:write: self._inConfig(item) 2022-03-29 07:06:10,104 Command udi_interface ERROR udi_interface:write: File "/var/polyglot/.local/lib/python3.8/site-packages/udi_interface/interface.py", line 598, in _inConfig 2022-03-29 07:06:10,108 Command udi_interface ERROR udi_interface:write: LOGGER.setLevel(self.currentLogLevel) 2022-03-29 07:06:10,108 Command udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/logging/__init__.py", line 1421, in setLevel 2022-03-29 07:06:10,114 Command udi_interface ERROR udi_interface:write: self.level = _checkLevel(level) 2022-03-29 07:06:10,115 Command udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/logging/__init__.py", line 198, in _checkLevel 2022-03-29 07:06:10,118 Command udi_interface ERROR udi_interface:write: raise ValueError("Unknown level: %r" % level) 2022-03-29 07:06:10,119 Command udi_interface ERROR udi_interface:write: ValueError 2022-03-29 07:06:10,119 Command udi_interface ERROR udi_interface:write: : 2022-03-29 07:06:10,120 Command udi_interface ERROR udi_interface:write: Unknown level: 'NULL'

Running PG3 3.0.54, and version 3.1.4 of this Node server, and I'm getting these errors in the log: 2022-03-29 07:01:21,446 MQTT udi_interface.interface INFO interface:_message: Successfully set wtcontroller :: ST to 1 UOM 25 2022-03-29 07:01:24,135 MainThread udi_interface.interface INFO interface:addNode: Adding node WirelessTagsController(wtcontroller) [None] 2022-03-29 07:01:24,137 MainThread udi_interface.interface INFO interface:setController: Using node "wtcontroller", driver "ST" for connection status. 2022-03-29 07:01:24,338 Command udi_interface ERROR udi_interface:write: Exception in thread 2022-03-29 07:01:24,339 Command udi_interface ERROR udi_interface:write: Command 2022-03-29 07:01:24,340 Command udi_interface ERROR udi_interface:write: : 2022-03-29 07:01:24,341 Command udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2022-03-29 07:01:24,342 Command udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/threading.py", line 932, in _bootstrap_inner 2022-03-29 07:01:24,347 Command udi_interface ERROR udi_interface:write: self.run() 2022-03-29 07:01:24,348 Command udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/threading.py", line 870, in run 2022-03-29 07:01:24,351 Command udi_interface ERROR udi_interface:write: self._target(*self._args, **self._kwargs) 2022-03-29 07:01:24,352 Command udi_interface ERROR udi_interface:write: File "/var/polyglot/.local/lib/python3.8/site-packages/udi_interface/interface.py", line 678, in _parseInput 2022-03-29 07:01:24,356 Command udi_interface ERROR udi_interface:write: self._handleInput(key, input[key], None) 2022-03-29 07:01:24,357 Command udi_interface ERROR udi_interface:write: File "/var/polyglot/.local/lib/python3.8/site-packages/udi_interface/interface.py", line 684, in _handleInput 2022-03-29 07:01:24,361 Command udi_interface ERROR udi_interface:write: self._inConfig(item) 2022-03-29 07:01:24,362 Command udi_interface ERROR udi_interface:write: File "/var/polyglot/.local/lib/python3.8/site-packages/udi_interface/interface.py", line 598, in _inConfig 2022-03-29 07:01:24,365 Command udi_interface ERROR udi_interface:write: LOGGER.setLevel(self.currentLogLevel) 2022-03-29 07:01:24,366 Command udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/logging/__init__.py", line 1421, in setLevel 2022-03-29 07:01:24,373 Command udi_interface ERROR udi_interface:write: self.level = _checkLevel(level) 2022-03-29 07:01:24,374 Command udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.8/logging/__init__.py", line 198, in _checkLevel 2022-03-29 07:01:24,376 Command udi_interface ERROR udi_interface:write: raise ValueError("Unknown level: %r" % level) 2022-03-29 07:01:24,377 Command udi_interface ERROR udi_interface:write: ValueError 2022-03-29 07:01:24,378 Command udi_interface ERROR udi_interface:write: : 2022-03-29 07:01:24,379 Command udi_interface ERROR udi_interface:write: Unknown level: 'NULL'

The error -110022 might be the cause. From the error codes listed in the wiki: -110022 OPEN FILE FAILED

I'll bet 3.0.46 deamon was still running, even though the newer version was installed. sudo service pg3 restart would have likely given the same results as the system shutdown/restart (it did in my case).

I don't know about the roomieremote, but it appears to be an IP based control system, so it should work just the same with a Polisy. Otherwise, if you're all Insteon/X10, you should purchase a Polisy and consider a migration plan. I doubt there'll be much development other than bug fixes for the ISY994i ZW Pro, as Polisy is the UDI platform going forward, and it's a much more capable device than the ISY994i. You could simply restore of a backup of your ISY994 on the Polisy and you'd be up and running. Z-Wave could come in time when you're ready to add devices (some Z-Wave dongles currently in the market are requiring upgrades to get past some issues, so it might be a good idea to wait a bit on that if you don't have an immediate need for it). If you're going to use the same serial PLM that your ISY994i uses, then I believe there's an issue with the cable that the ISY994i uses (you'll need to use the cable that came in the packaging). If you have a USB PLM, then no issues at all. Just keep in mind that IoP is under heavy development at the moment.

I haven't turned on the system yet, still too many freezes overnight, and I'm still running on my ISY994 and PG2, not IoP and PG3. The Node server is running normally...

Well, I simply checked for status of this single detector (the status on this detector changed when any of my other hardwired detectors saw smoke), and this always worked as intended. I replaced these detectors with wireless Elk detectors quite a while ago, so this solution is no longer in use, but it worked: Smoke Bridge - [ID 004D][Parent 0013][Not Enabled] If 'Devices / dirMasterBedroom / Smoke Bridge-Smoke' Status is On Then Set 'Devices / dirLivingRoom / ZW 007 Siren' On Wait 2 seconds Set 'Scenes / scnAllInteriorLights' Fast On Wait 2 seconds Set 'Devices / dirGuestBedroom / flcFan-Light' Fast On Wait 2 seconds Set 'Devices / dirGuestBedroom / sldGuestVanityLight' Fast On Wait 2 seconds Set 'Devices / dirGuestBedroom / sldGuestShowerLight' Fast On Wait 2 seconds Send Notification to '3' content 'Smoke Detector Alert' Wait 5 seconds Set 'Devices / dirLivingRoom / ZW 007 Siren' Off Else - No Actions - (To add one, press 'Action')

@xlurkr, if you need a hard wired detector, it looks like Amazon still has these: https://www.amazon.com/gp/product/B000EVO9D4/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1 I put one of these in, connected it to the Smoke Bridge, and it worked as expected.

@stevehoyt, for the programs that are yellowed and say "Out of Memory" in the status page, the first thing to try is to simply re-save these programs. They may or may not need an edit (I would inspect them), but clicking on the "Save Changes" button might restore the functionality of the programs. This is a problem that was encountered often when folks upgraded from the v4.x.x firmware to 5.x.x firmware in the ISY994. It's a simple thing to try, at least...

My ISY994 has the correct time for sunrise/sunset (v 5.3.4), and my IoP has sunrise/sunset an hour later (v 5.4.1_2). The 'date' command on my Polisy indicates that the time on the machine is correct.