Jimbo.Automates

Fixed

I don't see how ro create a program in UD Mobile that triggers from a variable change. For the "if" the only choices are schedule, control, status, parentheses and comment.

The Polyglot Version 3 Node server for ELK Security Version 3.6.5 is released. See the Release Notes This release added support for ELK Lights see Light Node. Since releasing and testing in my production environment I realize there is an issue since ElkRP has a 12 character limit for device names. If your device name is longer you are forced to use the node address which works perfectly but visually is not ideal in the ELk interface. Please provide feedback on this if you use this feature. This may necessitate adding the ability to export/import which is a fair amount of work. See the README for more information, including information on moving from PG2. If you have issues or requests please check PG3 ELK Github issues to see it has already been listed. And if you want to thumbs up an issue I will try to prioritize fixing the ones with most votes.

Yes, the version issue is understood and no reason to keep restarting mode servers just for that issue. Bob and I had discussed that issue before you reported it, and as he mentioned in another post it is fixed in the new interface but will take a while to propagate to all installations. Sent from my Pixel 6 Pro using Tapatalk

This looks similar to an issue that @bpwwer is looking into. Sent from my Pixel 6 Pro using Tapatalk

It's really hard to read a log inserted directly in a post, please edit the post and inset the log as code using the "<>" icon in the forum, or just attach it. May need help from @bpwwer to debug this.

They would not. There is nothing the NS can do to control X10 devices, it can only happen thru the ISY.

It's been out. Refresh your store. Sent from my Pixel 6 Pro using Tapatalk

Should be fixed in 3.0.20, the error still shows until python-kasa is fixed, but it doesn't cause the NS to crash.

The Polyglot Version 3 Node Server for Kasa TP-Link 3.0.21 is released. See the README for more information, including information on moving from PG2. The Release Notes are also available.

Having Lights configured in ElkRP2 that do not exist in ISY will not cause an issue, so not sure why I need a toggle to enable this?

This looks like a bug in a library I reference, I've submitted a bug report to them. I can add a trap for if they don't fix it soon.

New discussion here:

New discussion here:

New discussion here:

I've been working on adding the ability for the Elk node server to handle controlling ISY Lights when Elk Lights are changed. But first a question for all existing users of the ELK nodeserver. Currently when you have a "Light" configured in the Elk, it will create a new node matching that name on the ISY. This was done because I didn't really understand what Elk Lights were used for. So when moving to allow the new way, I plan to have the node server delete these ISY Light nodes that it created. Is everyone okay with that? The way it will work with initial release is you create an Elk Light and make it's Name be the same as the name or address of the ISY node you would like to control. There will be no export/import functionality on initial release due to the effort required, and in my opinion, it's pretty easy to just manually configure the Lights in ElkRP2 so it's not worth the effort. But, I've built in the basics for doing this, so it could be added in the future if the new method is not satisfactory. These changes have been made, and hopefully I can complete testing and get it released soon. - Jim

Moving devices should not matter. Any errors in the node server log? Download log package and PM it to me. Sent from my Pixel 6 Pro using Tapatalk

Ok, that is why discovery won't work with eisy when on WiFi. No idea how this can be resolved. Sent from my Pixel 6 Pro using Tapatalk

Thanks, had to restart then push the black button. All good now. But, this NS doesn't report any connection state or heartbeat that I could see? Sent from my Pixel 6 Pro using Tapatalk

It's add that PG3 -> PG3x migration didn't just keep your existing hubs. I just did that migrating last weekend and it worked fine. Is your eisy connected to Ethernet or WiFi?

I migrated to eisy and noticed Caseta NS wasn't running, in PG3 UI it says "press the black button", I changed log mode to debug that message went away and now it just keeps printing: 2023-03-14 08:35:22,212 MainThread udi_interface DEBUG controller:start: Waiting for configuration False 2023-03-14 08:35:27,219 MainThread udi_interface DEBUG controller:start: Waiting for configuration False 2023-03-14 08:35:32,221 MainThread udi_interface DEBUG controller:start: Waiting for configuration False 2023-03-14 08:35:37,321 MainThread udi_interface DEBUG controller:start: Waiting for configuration False 2023-03-14 08:35:42,322 MainThread udi_interface DEBUG controller:start: Waiting for configuration False 2023-03-14 08:35:47,347 MainThread udi_interface DEBUG controller:start: Waiting for configuration False 2023-03-14 08:35:52,359 MainThread udi_interface DEBUG controller:start: Waiting for configuration False 2023-03-14 08:35:57,360 MainThread udi_interface DEBUG controller:start: Waiting for configuration False 2023-03-14 08:36:02,364 MainThread udi_interface DEBUG controller:start: Waiting for configuration False 2023-03-14 08:36:04,301 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-03-14 08:36:04,302 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-03-14 08:36:07,369 MainThread udi_interface DEBUG controller:start: Waiting for configuration False Restarting and it shows press the black button again. Is that necessary after migration? Also, is there any way to monitor this NS on the IoP to send notifications if it's not running?

Sorry no progress. Work & life have been crazy the last few months. Finally had a little spare time so migration from polisy to eisy complete and first on the NS fix list is ELK. Sent from my Pixel 6 Pro using Tapatalk

It didn't matter how many times backup was run, they were all corrupt. But I was able to open the file and view the contents which showed a PG3 error due to an invalid soft link I had created a while back while debugging an issue.

Well crap... pg3 backup zip file is corrupt...

I saved the backup on my Polisy, and trying to migrate from PG3 backup on my eisy. 3/11/2023, 15:05:00 [pg3] info: Processing: {"method":"POST","url":"/frontend/restoreFromPG3","header":{"host":"192.168.86.89:3000","connection":"keep-alive","content-length":"1321","accept":"application/json, text/plain, */*","authorization":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjp7Im5hbWUiOiJhZG1pbiIsInBhc3N3b3JkIjoiYWRtaW4iLCJpZCI6IjEwMCIsInJvbGUiOiJhZG1pbiIsImdyb3VwcyI6IltcIkFkbWluaXN0cmF0b3JzXCJdIiwiZW5hYmxlZCI6MX0sImlhdCI6MTY3ODU3NTg0NywiZXhwIjoxNjc5MTgwNjQ3fQ.iyy8rxV3f3FVXLYV8CL_TGGuH0d6iVz_6csNEhycfBI","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36","content-type":"multipart/form-data; boundary=----WebKitFormBoundaryyNcgYSqNrR132KLi","origin":"http://192.168.86.89:3000","referer":"http://192.168.86.89:3000/backup","accept-encoding":"gzip, deflate","accept-language":"en-US,en;q=0.9"}} 3/11/2023, 15:05:00 [pg3] error: RestoreFromPG3: Error: FILE_ENDED at PullStream.pull (/var/polyglot/node_modules/unzipper/lib/PullStream.js:83:28) at PullStream.emit (node:events:513:28) at PullStream.<anonymous> (/var/polyglot/node_modules/unzipper/lib/PullStream.js:20:10) at PullStream.emit (node:events:525:35) at finish (node:internal/streams/writable:748:10) at node:internal/streams/writable:726:13 at process.processTicksAndRejections (node:internal/process/task_queues:82:21) All packages were updated this morning, and migrated from Polisy.