Jimbo.Automates

Yes, those ERRORS happen when node server is stopped or restarted, I need to figure out fix, but it shouldn't cause an issue. Interesting that you are seeing a delay on Polisy, we are seeing that on eisy but hadn't seen an issue on Polisy. You say library version 2.2.1, is it for this? [admin@polisy ~]$ sudo -u polyglot pip list | grep elk elkm1-lib 2.1.0 The node server doesn't support 2.2.0 or above, and specifically excludes that from the install so not sure how that happened? Edit: and besides that issue, I am running the same versions on both my Polisy's and see no delay.

Thanks missed that, guess I'll pull it back down tomorrow and pull it out if I don't hear back from support.

I did this on my lake house Polisy, staying on Polisy for now and added internal Zmatter board. After starting the restore I brought up AC and saw all zwave devices were disabled, then it started popping up the "Performing -Wave Device Interview" for each device and they were coming back enabled. Some devices take a very long time and the display will say "[Device 11] Waiting on interview complete (timeout in 400)" then the timeout number will drop to 399, then go back to 400, and ever minute our so it will show a device message. But it's been stuck on this same device for over 20 minutes. I submitted a ticket. My question is, can I leave the internal ZMatter board installed, then plug back in the Zooz dongle, reboot and restore my previous backup? Or do I need to pull out the ZMatter board? I left for a while and when I can back it completed, but Z-Wave X-Ray All devices shows: Devices list: 1 Interview Not done 5 Interview done 6 Interview Not done 7 Interview done 8 Interview Not done 9 Interview done 10 Interview done 11 Interview Not done

I had a bad experience disabling WiFi. Michel has been trying to debug. I did the 4 button press as described on the wiki to fix it. Sorry I'm not sure I can change it and get it tested tonight. I'll try to take a look while at our lake house for the next couple weeks. Sent from my Pixel 6 Pro using Tapatalk

I suspect updates won't be pushed since the wireless tag hub needs to know the IP address of the node server machine and it probably used that weird WiFi one. Sent from my Pixel 6 Pro using Tapatalk

That bogus address is likely because WiFi is enabled, there are currently issues with using some node servers with WiFi enabled. I can fix this in the Node Server but not sure if I'll have time today before I head out of town tomorrow. Sent from my Pixel 6 Pro using Tapatalk

Should not be related to the apostrophe's. After setting change_node_names to true, set Log to Debug, restart the node server, download log package and send that to me.

Best to reserve the IP address in your router DHCP. I think you have to get the USB adapter from UDI store? Sent from my Pixel 6 Pro using Tapatalk

Not sure what would cause that error, maybe @bpwwer has a clue. The license issue may need @Michel Kohanim to look at the database, I had a similar issue. But first please try to reinstall in the same slot, don't delete and reinstall, use the reinstall option in the store. Sent from my Pixel 6 Pro using Tapatalk

This is taking a while to debug. It works fine outside of the node server, so I'll need to write some custom code that uses the library in the same was as the node server and see if that shows the issue. The 'write_msg' is displayed immediately before it tries to actually send the data to the ELK so I'm have no idea why it would take so long to print that message.

I had initially enabled WiFi, but switched to Ethernet and kept having problems. I just reset networking with the 4 button pushes described in the user guide and it seems better so far. https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#Reset_Networking

Yes that's the correct link, thanks for checking. If you order after clicking the link it will be credited. Sent from my Pixel 6 Pro using Tapatalk

What is your PG3 version? Should be .18 Sent from my Pixel 6 Pro using Tapatalk

It's not the password, it's a ELK user code like the one you use at the panel. I created a unique one specifically for PG3. Also, remember you are using eisy and a version of PG3 that's had many recent changes so there are bound to be issues. Also, the ELK NS has had very little testing on eisy. My eisy is having issues right now so I'm unable to test... Sent from my Pixel 6 Pro using Tapatalk

The doc: https://github.com/UniversalDevicesInc-PG3/udi-poly-ELK/blob/master/README.md#zone-node Shows Logical Status driver:ST If it's still showing the raw value try rebooting the ISY. It returns the correct for output because that uses a standard On/Off so a reboot is not required.

Thanks @bpwwer , that explains it. Sent from my Pixel 6 Pro using Tapatalk

I finally got my eisy working and I see the same issue, this looks to be a network issue with eisy sending data to the local ELK python library which then sends the data to the ELK. I'm not sure what to do about this, will need to discuss with @Michel Kohanim The log below shows the NS sending the arm command to the library at 12:37:52 but that library doesn't receive/send the data to the elk until 20:38:09. 2023-01-07 20:37:52,945 Command udi_interface INFO Area:cmd_set_armed_status: area_1:Home: elk.arm(0,**** 2023-01-07 20:38:09,114 ELK-5703 elkm1_lib.connection DEBUG connection:write_msg: write_data '0Da010031960037' 2023-01-07 20:38:09,115 ELK-5703 elkm1_lib.connection DEBUG connection:_read_stream: got_data '16XK24252070701230100072' 2023-01-07 20:38:09,115 ELK-5703 udi_interface INFO Controller:callback: ELK Controller: cs={'real_time_clock': '2425207070123010'} 2023-01-07 20:38:09,115 ELK-5703 udi_interface INFO Controller:callback: real_time_clock=2425207070123010 2023-01-07 20:38:09,132 ELK-5703 elkm1_lib.connection DEBUG connection:_read_stream: got_data '1EAS2000000041111111000000000009' 2023-01-07 20:38:09,132 ELK-5703 udi_interface INFO Area:callback: area_1:Home: cs={'arm_up_state': <ArmUpState.FULLY_ARMED: '4'>} 2023-01-07 20:38:09,132 ELK-5703 udi_interface INFO Area:set_arm_up_state: area_1:Home: ArmUpState.FULLY_ARMED What I am not sure of, is does the 'write_msg' debug line print when it starts the write_msg, or when it completes. I'll look into that tomorro, and I will try pulling the NS out of the equation by just using the python library to send commands to the ELK.

Yeah, for sure I realize that when it was envisioned PG would be running on different machines talking to the ISY, but now that it can be on the same machine that makes sense. But mine was someone configured to an IP not valid on my LAN 192.168.1.127, I changed it to localhost, restarted and it's good now.

You mean all slots in the ISY admin console Node Server configurations? Sent from my Pixel 6 Pro using Tapatalk

Can't it use localhost instead of an IP address when it sees ISY and PG3 are on the same machine? I actually changed all mine to localhost per Michel when I reconfigured my network addresses a while back. Sent from my Pixel 6 Pro using Tapatalk

You can only create tickets using the web interface, sending to support email doesn't work anymore, or it hasn't worked for me for a while. Sent from my Pixel 6 Pro using Tapatalk

This can't be a random number, it needs to be a valid user code defined in your ELK system. Personally I create a specific user code for PG3 so I know who is arming/disarming the system.

Did you reinstall in same slot? If so, will need need help from @bpwwer for these error.

Please update to the latest PG3, reinstall in the same slot and try again. Sent from my SM-X808U using Tapatalk

Sorry I have no idea. My eisy had issues last weekend so I wasn't able to test. It's all good now so hopefully I have time this weekend to test. Sent from my SM-X808U using Tapatalk