JSylvia007

It was exactly that. Might want to update your documentation saying that Ambient can take a long time to activate the API Key. In my case I played with it for almost an hour and it didn't work. This morning I restarted the service in Polyglot and it all came through immediately.

I just installed this plugin, and there appears to be an API issue with the response parsing: 2024-07-11 19:31:27.074 MQTT udi_interface.interface INFO interface:_message: Profile installation finished 2024-07-11 19:32:24.346 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2024-07-11 19:32:24.347 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2024-07-11 19:32:24.347 Command udi_interface.interface DEBUG interface:_handleInput: PROCESS shortPoll message {} from Polyglot 2024-07-11 19:32:24.347 Thread-3 (poll) udi_interface DEBUG ambient-poly:poll: ShortPoll: shortPoll True https://api.ambientweather.net/v1/devices?applicationKey=7651edae3d7b44ee8ab5c3359b0c99469f30bf3d2a1d4f2c995b25d9c01a2cd3&apiKey=REDACTED 2024-07-11 19:32:24.479 Thread-3 (poll) udi_interface ERROR station:Query: Parsing failed: string indices must be integers, not 'str'

Assuming that any of us who already own the ZMatter USB don't have to do anything and this is a certification of the CURRENT device? We don't have to upgrade hardware? Perhaps a firmware update?

Ticket submitted with some initial findings.

Since @Michel Kohanim can't be messaged directly on the forums, I figured I would tag him here... Good afternoon Michael! Overall I'm very pleased with the eisy and I'm glad I did the migration (although it was quite expensive). I do have some security concerns, however. There are definitely some default configurations with BSD that you guys have overlooked. I have over 20 years of professional experience with Operational Technology, SCADA/ICS, and IoT. If you folks want some help (free of charge obviously), I'd love to provide some insight. You're creating a product that literally controls people's homes, and hackers are EVERYWHERE.

Would you consider adding a status box to updates in the Admin Console like you do for backups, that way there is an indication to the user that SOMETHING is happening?

So I see that there is new firmware. I opened the admin console and clicked "Upgrade Packages". Said "ok" to the two pop-ups. The update process starts and says "this could take 30 minutes" and then just sits there. There should be some other message that allows for tracking the upgrade... I had no idea what the indication would be, until about 10 minutes in, another popup indicated that I needed to reboot. I understand that we're working with a bit of old technology here for the admin console, but we HAVE to get better with this stuff. The user experience is still pretty lacking, and there are some MAJOR security configuration vulnerabilities in the underlying OS. Don't get me wrong, BSD was the right choice, and it's an excellent choice for security, but some of the system defaults are way too insecure in 2023, and the necessary admin tools to fix them aren't for the average user to tackle. If anyone at UDI is willing to work with me, I have 20 years of Control Systems / Operational Technology Cyber experience and I'm willing to offer advice.

This is a good point. I always forget that the official ticket system exists

It looks like although I did all the steps, I needed to re-do the z-wave synchro ones again... Makes no sense. EDIT: I'm also not sure if this is going to fix it either. Only time will tell.

I'm on the latest firmware and everything was working just fine... Then, randomly my programs with z-wave devices stopped working. I went into the admin console, and the problem Z-Wave devices have disabled nodes... They were working just fine, but somehow without me changing anything, they became disabled. In the image below, all the nodes that have a funky name in the far right column were somehow disabled: I right-clicked and selected "enable" and then the programs started working, but as you can see, the item that ends in " - Motion" has a funky type associated with it, and that actually prevents me from modifying the program, because I can't actually pick that node. So, it's "working", but it's not exactly ideal. Tomorrow maybe I will try another interrogation pass on it to see what that does. Might do that on the door-locks too... Overall the Insteon devices have been rock solid, but Z-Wave support here on eisy and other universal devices products remains... less than stellar.

Even more investigation... It appears that the motion generating items are now unpickable in the element picker in the programs... Guys... WHAT is going on... You went from a relatively stable device in the ISY, granted Z-Wave has always been a bit of a shit-show, bit man... This is a pretty crappy step back. Going to try to reboot the eisy and see what happens, but this doesn't bode well. Am I really going to have to re-add ALL my Z-Wave devices? Will that even work?

Further investigation shows now that none of my Z-Wave triggers are working either (motion sensor to turn on an Insteon light)... And many of my Z-Wave devices are now showing disabled... I haven't touched anything... Literally everything was working, I've touched nothing, and now things are funky... This doesn't bode well... Something so critical really needs to be stable.

So... I've come to really rely on my Universal Devices setup... I've migrated everything over to an eisy, everything appears to be functioning well... What's not working well are my z-wave door locks when tied to programs. I have a "I'm leaving" program that locks all my deadbolts, and it was rock solid, worked every time with the ISY994, but now, with the eisy, it NEVER locks my deadbolts. I can control them manually without issue (although sometimes they lag badly - minutes), but the program never locks them. I created a program that JUST locks them, and that's somewhat reliable from what I can tell, but when I add that program as a step into my original program (and replace the lines that specifically locked them), it again fails to work. Is this a known issue?

You're only mostly accurate here. The values displayed are not nodes... Nodes are the entities that contain the values... And while you're correct about Integer and state variables being variables, there are also substitution variables (which is what I was referring to), and is their actual name in the Wiki (link above), is literally "Substitution Variables". This is also not accurate. I recommend that you read the link I actually posted about variable substitution on the Wiki...

For anyone coming here with a similar issue, this answer above is the correct answer to determine what properties are called for a given node: 1. Right-Click on the node in the left hand tree of the admin console and select, "Xray". 2. In the new window, change the top-left drop-down from "Node Object" to "Node Info", and click the "Go" button next to it. 3. In the text window below, all of the properties will be shown. The ID portion at the end of each line is that is needed for the Email Notification Variable Substitutions.

I'm not creating variables. I was trying to use the EXISTING Variables (as stated here in the EMail and Networking Substitution Variables). The issue was that the migration CHANGED what the existing variables were, and it wasn't intuitive to what they changed... In the screenshot below, the item circled in red used to be called "STATUS", but now it's called "ALARM", and I had no way to know that without getting to the behind the scenes stuff. If you take a look above, BATLV wasn't the issue. The issue was the status. This is exactly the setup that I have. I have one program that monitors all the battery devices, and if one of them is below 20%, it calls an email customization that lists all the battery devices, their STATUS (open, closed, etc.), and their current BATLVL. The problem is that certain devices after the migration no longer had a STATUS, they have an ALARM (but I didn't know it was alarm, and I didn't know how to find it, hence why I asked the question to find out what it might be called).

It's a script that I use to pull the status of all the battery-operated devices. I travel a bunch, and its nice to know what the battery levels are, as historically, "LOWBATT" alarms for ZWave devices are TERRIBLE. Thanks for the above tip. I didn't know it existed! This is great. I was able to find out that the variable that I needed was ALARM, but it appears that ALARM doesn't get properly translated in the notification variable. I'm using just .ALARM, not .ALARM.RAW, but I'm getting the value 0, instead of Idle. Perhaps this is something for the developers, @Michel Kohanim?

I have finally gone through my migration from the 994 to the eisy. It certainly wasn't smooth, BUT, I think I'm through most of it. One issue that I have is that some of my Aeotec Z-Wave door/window sensors no longer report their Status via the status variable (${sys.node.ZY016_1.ST), as it appears that it's now called "Access Control". What variable should I be using in notifications if I want that value? .ST isn't working, and the wiki page doesn't have something called "Access Control", only items related to user access codes.

There's not a drop-down, there's a selection, and the nearest city is 100 miles from me. I want to use my lat/long. Why can't I use the correct lat/long?

OK. So... I'm most of the way through the migration (it's doing the PLM piece now for the Insteon Devices). MANY of my Aeotec Z-Wave Devices remained in "Placeholder" status, because they're all battery operated. Is there a trick to getting these devices to come online, or am I going to have to visit EVERY one and "unlink" / "link" tap dance to bring them back? Second... And I can't believe I can't really find a solution or link to this explaining the answer... Why does the LOCATION setting not allow a negative longitude? Last (for now)... There are MANY settings that don't actually transfer over. SMTP settings, IP Port settings... This really should be documented better, you guys have had a LOT of time to get this right...

Ok, that's good info. So it wasn't Aeotec Z-Wave stuff... My stuff is exclusively that.

Woah... This would be a non-starter for me... What brand of Motion & Door Sensors are you using??

Howdy. I currently have an ISY with the RJ45 Serial PLM, and the newest upgraded Z-Wave module. My network is a healthy mix of Insteon & Z-Wave. I have also purchased an eisy, a Z-Matter/Z-Wave USB Dongle, and one of the NEW Insteon USB PLMs. My plan for migration is as follows... Create backup from existing setup, and store in safe place. Physically disconnect the ISY & old PLM Physically connect the eisy, Z-USB Dongle, and the USB PLM. Perform whatever initial steps are recommended to get it on my network. Run any recommended updates (packages, etc). Restore the backup from the ISY to the eisy. Perform a PLM Update to "notify" all my Insteon devices. What do people think about that? Any "gotchas" that folks have run into? Anyone who's already done the swap, how long did it take? Thanks in advance!

So I've now ordered a zmatter board (usb) for the eisy, and a USB PLM for the eisy... And I'm in the same boat as you folks. I can't get a straight answer when the actual eisy itself will become available again... Maybe it will go the way of polisy... Maybe the eisy is already OBE, and we'll get a fisy. Maybe they'll skip the fisy all together and go straight to the jisy...

Well then... Given all the time this stuff is going to take to get released, this seems like $80 well spent... LOL.