landolfi

Right, it doesn't make sense that it would have anything to do with Zmatter but I thought maybe the restore of the migration backup might have somehow corrupted the Insteon config. I noticed a similar issue with a second LampLinc showing blank status/on level/ramp rate right after performing the software update to 5.6.2 yesterday.

Is anyone else having periodic issues with Insteon devices after migrating from Zmatter? I only have one active Lamplinc, it was rock solid until I migrated to Zmatter. It has gotten "lost" several times, i.e. blank status values in AC and not turning on as scheduled, and I either have to query it or restore it before it will respond. Maybe it's just the hardware failing and the timing after migration is a coincidence? The PLM is working OK with turning on an X10 device, it sends X10 commands shortly after turning on Lamplinc.

I could send you what entities Home Assistant reports (e.g., GW2000B_V2.2.4 Rain Rate Piezo), but I think you are looking for a full API spec. This one seems to cover rain, soil moisture, and lightning, which are my use case: https://osswww.ecowitt.net/uploads/20220407/WN1900 GW1000,1100 WH2680,2650 telenet v1.6.4.pdf It also appears to be the very latest.

Is this node server being maintained? I am only getting the following nodes: Indoor, Outdoor, Wind, and Pressure. It appears this node server does not recognize the Wittboy rain sensor, nor am I getting any reports from a lightning sensor. I got this node server on the assumption I'd be able to monitor rain. Is there an alternate configuration or a planned enhancement that will report on all the devices that are connected to the GW2000?

All working now! Thanks very much. I had the impression that PGx was only for eISY, not sure where I got that idea. Anyway, a few things that weren't clear in the PG3x upgrade: 1) The enabling PG3x link just opened a browser page that said: This XML file does not appear to have any style information associated with it. The document tree is shown below. So it wasn't clear whether that step worked or not. I did it twice, then proceeded on the assumption that it had worked. Some sort of confirmation that it worked would have been helpful. 2) The process was complicated by a dialog from IoX saying I needed to upgrade packages. Not sure whether that nessage was related to #1 or just coincidence. If it was related, it would be nice to know that was going to happen. The PG3x upgrade instructions make no mention of it. 3) I had to log out before PG3x would reconnect (even though it was actually connected as far as IoX was concerned). I don't know whether that's a step missing from documentation or specific to my Polisy situation. For ST-Ecowitt setup, at least for the GW2000, the port referred to in the setup instructions is the NS port and it says that. But the hub already has a default port when you configure a custom service, so I thought I was supposed to set the NS listenPort = the hub default. In fact, it's the other way around: The hub is supposed to get whatever value listenPort is set to on the NS. The instructions could make this clearer by telling you to explicitly set a listenPort value as a custom NS parameter BEFORE doing the hub setup. Also, don't use port 80 because you'll get constant "ST-Ecowitt NS is online" notifications from the ST-Ecowitt node server on your UD mobile app.

I followed the instructions, and now all my node servers are working, but when I try to go to the PG3 node server using the Node Server menu on IoX, I get a message saying the PG3x server isn't connected and the message will disappear when it is. I've tried restarting PG3x and refreshing the page, neither works. Is this expected and if not, what's my next step? EDIT: Logging out of PG3x and then back in seems to have fixed it.

Tried reinstall again, it is still failing at startup. Can a Polisy run PG3x? And is there a way to install just the missing file?

I'm running 3.1.21, Polisy with IoX 5.6.0. I did try a reinstall yesterday (deleted and re-installed after the purchase), but I can try that again.

I wondered about leaving keep awake on to see if they'd report reliably, but yeah, it makes sense I'd need to turn that off again. I created a special ISY folder just for the keep awake settings. I have a lot of solid Aeotec products, so that might be next for me too. My Zooz wired stuff was always reliable, so when I saw a chance to pick up these battery devices relatively cheaply, I figured why not. I imagine many others are in the same boat. I too have been noticing some bizarre Zwave behavior including untrapped Java errors in the IoX code when I query devices. I thought I was migrating on the tail end of the Zmatter issues, but now I'm not so sure...

Yes, but it seems (and has always seemed) inaccurate. When I remove the batteries and test them they are always around 2.93V, but the battery report will typically show 30%. It could be the batteries I'm using, they're off-brand Amazon cheapos (LiCB brand). I noticed the documentation says pairing can cause drain that the battery will recover later.

I just bought the ST-Ecowitt node server for PG3 hoping to use it with an Ecowitt GW2000 hub, and I have it configured as a custom weather service on the hub. I have it the nodeserver configured with a custom parameter listenPort as per instructions. But when I try to start the node server it immediately fails with: 2023-06-01 08:18:20 info: NS: Starting Node Server 2023-06-01 08:18:20 error: NS: uncaughtException REPORT THIS!: Error: Cannot find module './lib/EcoWittServer.js' Require stack: - /var/polyglot/pg3/ns/000db95d9b24_8/st-ecowitt.js at Module._resolveFilename (node:internal/modules/cjs/loader:1039:15) at Module._load (node:internal/modules/cjs/loader:885:27) at Module.require (node:internal/modules/cjs/loader:1105:19) at require (node:internal/modules/cjs/helpers:103:18) at Object.<anonymous> (/var/polyglot/pg3/ns/000db95d9b24_8/st-ecowitt.js:33:23) at Module._compile (node:internal/modules/cjs/loader:1218:14) at Module._extensions..js (node:internal/modules/cjs/loader:1272:10) at Module.load (node:internal/modules/cjs/loader:1081:32) at Module._load (node:internal/modules/cjs/loader:922:12) at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) 2023-06-01 08:18:20 error: POLY: uncaughtException: Cannot find module './lib/EcoWittServer.js' Require stack: - /var/polyglot/pg3/ns/000db95d9b24_8/st-ecowitt.js Error: Cannot find module './lib/EcoWittServer.js'

Thanks for the reply. I got the ZSE40 and ZSE 44s included finally. Not sure what the secret was other than desparately working to keep them awake during the interview, but they are included and reporting status now. As I recall I used unauthenticated S2 for at least the ZSE44s because I didn't know the PIN. The ZSE40 had the PIN printed on the cover but I wasn't sure whether to accept the DSK it showed or not (I did).

Holy cow I had no idea what a pain in the behind this would be. Since I migrated to Zmatter and running 5.6.0 firmware, ZSE44s and a ZSE40 are both 1) failing to update and then 2) disappearing after failed interviews. Interviews are timing out and thus failing even with repeated button presses to keep them awake. I'm even having difficulty getting them to exclude. I've also tried to force remove but when I try the "remove failed nodes" option I get some kind of internal application library error. There have been a couple times the nodes for these devices got included, but when I query the device nodes I get socket and other miscellaneous Java errors. The devices are about 10 feet away from the Polisy/Zmatter board. (Yes the antennas are connected correctly). I have Keep Awake on, but that node disappears from time to time when the interview fails. Often the devices go to sleep anyway. I'm now trying to include them with S2 off. That hasn't worked any better so far, but it's a recent development, I figured I'd come here to see what other ideas I might try. Is there any hope that these will work properly once I have them included? I thought I was already past this, they were working once post-migration, but that was short-lived.

Thanks for looking into the counter. The way my IoX program works, the IoX email notification (which simply tells me that the valve is on) is supposed to occur immediately after the off delay is set. It seems to me that would mean it takes a second to set the off delay and then send the email. But for some reason IoX is not sending that email notification until 15 minutes later. As if the valve off delay takes 15 minutes to complete successfully as far as IoX is concerned. So the sequence as it is: 1) Valve open at 0800 (which it always does), set off timer for 20 minutes (which takes 15 minutes to complete), 3) send email notification that valve is open (occurs 15 minutes after original valve open at 0800. Also I forgot to mention that the valve shuts off at 0820. So apparently the delay is getting set immediately at 0800 as it should. It only did the battery % once that I saw (it showed 99%).

Battery level is back. I hadn't changed anything and it looks like I'm still on the same version. Friday battery level showed %, now it just says Medium. EDIT: This device seems to be really flaky in reporting its status. For a period just now it was showing all attributes except the timer delay time remaining, then it showed the timer delay but all other attributes were unavailable, now it's showing everything including the timer delay countdown. But the timer delay is already over, the valve has been closed for 7 minutes, and it's still counting down showing 8 minutes to go.

Just noticed that the battery level for the valve controller is gone. It was there when I first installed 0.8.97, but I no longer see it. I restarted the node server just to be sure and it's still missing.

Thanks for adding battery level! Still getting the error/Yolink failure notification (log entry below) but I think you said it will continue. I just ignore the email I get from Yolink, so it's not an issue since the operation always works. 2023-05-27 08:15:04,451 Thread-1078 udi_interface ERROR yoLink_init_V3:process_message: Non-000000 code Can't connect to Device : {"code": "000201", "time": 1685193304409, "msgid": "1685193300216", "method": "Manipulator.setState", "data": {}, "targetDevice": "d88b4c0100060595", "desc": "Can't connect to Device"} 2023-05-27 08:15:04,452 Thread-1078 udi_interface INFO udiYoManipulatorV2:updateStatus: updateStatus - udiYoManipulator 2023-05-27 08:15:04,453 Thread-1078 udi_interface ERROR yolink_mqtt_classV3:updateCallbackStatus: Manipulator: Can't connect to Device 2023-05-27 08:15:04,456 Thread-1078 udi_interface.node ERROR node:setDriver: 8b4c0100060595:YoLink Valve Invalid driver: BATLVL 2023-05-27 08:15:04,533 MQTT udi_interface.interface INFO interface:_message: Successfully set 8b4c0100060595 :: GV1 to 0 UOM 57 2023-05-27 08:15:04,568 Thread-1079 udi_interface ERROR yoLink_init_V3:process_message: Non-000000 code Can't connect to Device : {"code": "000201", "time": 1685193304483, "msgid": "1685193300260", "method": "Manipulator.setDelay", "data": {}, "targetDevice": "d88b4c0100060595", "desc": "Can't connect to Device"} 2023-05-27 08:15:04,569 Thread-1079 udi_interface INFO udiYoManipulatorV2:updateStatus: updateStatus - udiYoManipulator 2023-05-27 08:15:04,570 Thread-1079 udi_interface ERROR yolink_mqtt_classV3:updateCallbackStatus: Manipulator: Can't connect to Device

Thanks for the excellent support! Will check it out now. EDIT: Just looked for it but the NS store still has 0.8.90. Will keep an eye out for it.

Thanks for clarifying. It's not the node server that sends the email, it's the Yolink server sending it (sorry for any confusion). I'm attaching it just for fun. Yes, I use the set off delay to get the 20 minutes. That "set off delay" function confused me in IoX until I looked at what was happening in the Yolink app after IoX had set the delay. I was able to see that the Yolink app was counting down from 20 to zero. Your explanation makes sense because it seems the device is pretty battery intensive. I don't see the battery level in the Yolink Valve node in the node server, but the batteries appear to be about 50% after only about 20 open/close cycles. YoLink Device Alarm YoLink Valve.msg

There really isn't any resolution necessary. See DennisC's comment above which is marked as Solution, all nodes are actually ZY but some retained their ZW name. The ticket is still open so I don't yet have any response on why I received an untrapped error.

I have a program that runs daily from 0800 to 0820 to water my garden. I send an on command to the valve, set the valve delay to 20 minutes, and then send an email notification to myself. Everything works fine. Not sure whether this is a Yolink issue, but at the exact time of the IoX email notification (0815), the Yolink server also sends an email telling me that the valve "failed to perform the operation". The PGx log shows an error at that exact time, but as I mentioned the on/set delay is sent at 0800 and the 20-minute off command works as scheduled, so not sure why the error would occur 15 minutes after the successful ON. Could the node server be sending an extra unrecognized command that is causing the Yolink failure notification? It's mostly an annoyance becuase everything is working. Log attached. YoLink_5-25-2023_62850-AM.zip

Turns out that this is exactly the situation, which caused my confusion (along with the untrapped error message I got when trying to remove them). Some devices have both ZW and ZY node names but in fact all are ZY. In cases where a device has both ZW and ZY node names, it appears that ZW were the device nodes that existed prior to migration and ZY the ones that migration created anew. It would be good if the migration instructions included this. Or maybe I'm on the trailing edge of the migrators and it doesn't matter.

I had this problem with Alexa after a Zmatter migration because the device names changed from ZW to ZY. I had to delete all the ZW nodes and replace them with the ZY. Unfortunately the migration instructions did not mention this possibility.

Turns out the valve sensor was acting strangely because I had the wrong size hose attachment adapter on the output side. For anyone else who might have one of these, the male NPT adapter for the output of the 3/4 model should be 3/4 to 1/2, not 3/4 to 3/4 as I thought. The Yolink marketing material shows a picture of a 3/4 to 1/2 but does not specify the actual thread sizes and there is no info provided with the valve, only the controller manual.

I opened a ticket with UD support. Will report results here.