f11

I performed the EISY upgrade (one push of front button), waited about 5 min, rebooted EISY (5 pushes of front button), waited a couple min while I cleared my java cache. Ran "start.jnlp", logged into Admin LAN console, checked the Zigbee box, Saved the change, restarted IoX, and then logged back in - Zigbee tab was in the top menu (even without plugging in ZMatter dongle). If you don't clear the java cache after the upgrade, you might get a message about mismatched SW and FW due to the upgrade (at least I did).

DennisC, you're absolutely right - my apologies. I meant both ISY and Polisy showed up in my IoX Launcher dialog, not the Admin Console, which is accessed THROUGH the Launcher Polisy link. The "Upgrade Packages" I selected and clicked was in the Launcher, under the Polisy link (I think - it was a while ago now). I access both the ISY (still connected to the PLM, and to my network over Ethernet) and the Polisy (no connection to the PLM and connected to my network via WiFi) via that IoX Launcher ... at least I used to. The ssh command I ran to do this last upgrade wasn't a generic FreeBSD/Linux package upgrade command, it was the shell command that I understand is run by the Admin Console, which I seem to recall Michel asked me run last July: <sudo /usr/local/etc/udx.d/static/udxops.sh upgrade.polisy> I do understand that doing genereic updates/upgrades are not recommended anymore as the Polisy/polyglot3 program evolves and becomes more involved. I just hate to show up again at Michel's doorstep with the Polisy again dead, he HAS to be sick and tired of my problems. And I'm pretty reluctant to junk the Polisy that I just spent recently more money on buying the new ZMatter board and antennae. Surely to gawd the Polisy appliance isn't dead and obsolete already.

I was trying to migrate my ISY994/IR to IoP on Polisy. Following instructions, I had the Admin Console on my screen, it showed both ISY and Polisy device MACs and IPs. I clicked on Polisy, then "Upgrade Packages", even though the instructions said "Update Packages". Polisy subsequently disappeared from Admin Console, and couldn't be found or added. I've power cycled. rebooted, gone into Polisy via ssh and restarted udx, poked a paperclip into that little front panel hole ONE time for upgrade (in case there was another upgrade needed), and on and on. Michel and I spent a LOT of hours getting my old Polisy (bought just after first announced) firmware updated last July, which involved re-flashing the onboard 32GB mSATA boot SSD. When we were done, Polisy was running and appeared ready for the migration process. By then I was mentally exhausted, and just let Polisy run unmolested for a while so "things could settle" (mostly me). I still marvel at how stubbornly Michel stayed with me to get my Polisy going again. The migration effort mentioned in my first post (leading to Instruction 2, to select "Polisy" in Admin Console, then select "Update Packages") was the first time I've touched Polisy since then. I noticed a couple things today that make me wonder: 1. running <sudo service udx restart>, I see amidst other less remarkable strings [admin@polisy ~]$ sudo service udx restart Stopping udx. Waiting for PIDS: 1231. Wed Mar 8 15:44:17 MST 2023|/usr/local/etc/rc.d/udx: precmd_start... Wed Mar 8 15:44:17 MST 2023|/usr/local/etc/rc.d/udx: sanity checking polisy ... Wed Mar 8 15:44:18 MST 2023|bash: running polisy sanity check ... 1 does not exist .... Wed Mar 8 15:44:18 MST 2023|/usr/local/etc/rc.d/udx: making sure all prereqs are installed ... sysrc: unknown variable 'pg3x_on_polisy' 2. running <uname -a> gets me [admin@polisy ~]$ uname -a FreeBSD polisy 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 #8 releng/13.1-n250180-01efaef88f1e-dirty: Mon Feb 13 20:38:47 UTC 2023 root@bsdev.isy.io:/usr/obj/usr/src/amd64.amd64/sys/eisy amd64 Perhaps I've somehow loaded into my Polisy an upgrade intended for the eisy device? I have no idea if this is even relevant, but the "root@bsdev.isy.io:/usr/obj/usr/src/amd64.amd64/sys/eisy amd64" reference in the response string makes me wonder if Polisy is trying to boot with eisy executables? Is this response to uname in Polisy normal? At the moment, my Polisy front panel is displaying the left-most LED lit solid; ssh is accessible with admin account; I can load what appears to be my local PG3 website into a browser at <https://192.168.x.x:3000/login>; only my ISY994 appears under menu item "ISYs" (and can't Add or Discover any other ISY); and the small identification panel at the bottom of the page displays PG3 Version 3.1.18 Status: Connected Frontend Version: 3.1.18 ISY Version: 5.3.4 Disconnected Uptime: 48 Minute(s) 2 Second(s) (c) 2023 UDI If ANY of this suggests an avenue to explore, short of repeating last July's reflash and start-over, I'm game. Edit: restarting polyglot3 from webpage under System, with Loging set to Debug, I saw these strings in the startup process, but not sure what they're trying to tell me: 3/8/2023, 17:09:15 [pg3] info: Query IoX for platform UUID. 3/8/2023, 17:09:15 [pg3] error: PID: TypeError: Cannot read properties of undefined (reading 'device')

After deciding I'd finally migrate my ISY994/IR to IoP, I followed the instructions in the Wiki to do so. One of the first things it says is to go the Admin Console, and click "Update Packages" for the Polisy. Hmm ... the button in the Admin Console reads "Upgrade Packages". I sat there paralyzed for a moment, as that kind of variance between instructions and reality in the past has always led to disaster. But what else could I do? I clicked on "Upgrade Packages". Nothing happened, no LEDs flashed, no beeps or boops, nothing. But knowing how slowly this black box crunchs through commands, I walked away from it for 4 hours to let it do its thing. Alas, after coming back to continue the migration process, my Polisy is dead in the water. I rebooted the box, and now I can ssh in and look around, I can log into the the web interfaces for PG2 and PG3, but I can no longer see Polisy in the Admin Console, nor can I add it. I experimentally deleted IoP in the PG3 webpage under ISY, hoping I could add it back - but no such luck: same as for the Admin Console, the IoP can't be discovered or found. I've read the threads here on Upgrading that lead others to the same problem, and tried their various solutions. None of them have helped me. I guess I'm left with reflashing the box to factory state, and starting from scratch. Again. I have no words to describe the frustration. I'm just not sure its worth another two-day effort, the hours and hours of Michel's time, trying this and that until we stumble upon the magic combination of commands and updates and reboots that gets it running. Until the next time. I can live with my trusty, bulletproof ISY which has asked nothing from me while providing years and years of quiet solid service.

Nope, after doing the push-the-tiny-button-just-once upgrade, waiting about 8 hours, then launching the Admin Console via the desktop IoX Launcher, Polisy doesn't appear, nor can Add / URL find Polisy or IoP in the Console. All the Console shows me is the ISY944. And even that takes almost a minute to appear on its own. So once again, this blue box is sick, and goes "into the shop" in the form of me submitting a ticket. Twice in 6 months. Even if its my fat fingers causing these breakdowns somehow - do I really want something this fragile automating my home? I appreciate some of you are having flawless experiences - good on ya - and that this IS a computer-in-a-box doing some complicated things in a niche hobby arena ... but that hasn't been my experience at all. If Michael hadn't spent hours and hours and countless emails with me last July helping to reflash/resurrect the box from near brain death, it would have been stripped for parts already for other projects I have going. Talk about frustrating. Off to submit a another ticket. Thx, Javi and larryllix, for trying to help, certainly appreciated!

Assuming Javi expected me to use the button inside the small hole to trigger an upgrade, I used my paperclip to push the button once, while the left-most LED alone was lit. These events were observed: - nothing happened for about 5 sec - 1 beep, left-most LED stayed lit solid - two right-most LEDs flashed fast (maybe 2-3 Hz) - flashing continued for about 30 sec - 5 evenly spaced beeps - two right-most LEDs went off, left-most LED stayed lit solid - Polisy stayed that way for 5 minutes Lets say that process ended at midnight. I won't do ANYTHING to the Polisy or any UDI software till morning. We'll see then if it made any difference to getting Polisy to show itself in the Admin Console. If not, then per Javi, its Ticket Time. Oh, in case its relevant - the serial PLM (2413S) is still connected to the ISY994, which is still controlling the house lights and reporting data gathered from weather and solar energy interfaces. i've rounded up the original Polisy serial cable (9-pin female D-Shell on one end, RJ45 connector on the other). As I understand it, I disconnect the ISY994 from the PLM and connect the PLM to the Polisy via its 9-pin male D-Shell later in the process.

Um, yeah. As I said, I don't have access to Polisy inside the Admin Console. I can only see the ISY994 in the Console. THATs the problem. Polisy doesn't show up in the Console on its own, and the Add / URL reports that the standard Polisy IP4 address can't be found. Given what you just said about the SSH upgrade path, I can only assume that Javi meant me to push the button accessible thru the small front-side hole to try an upgrade?

What method for upgrading do you want me to follow: - single push of front panel button - ssh into Polisy and follow upgrade process as described here: <If Polisy is old, you will need to SSH to the Polisy and update it manually. You will need the IP address of your Polisy. Instructions for a PC can be found here: https://forum.universal-devices.com/topic/34348-very-simple-instructions-requested-to-get-isy-on-polisy/?do=findComment&comment=324026 > - some other method?

Could use a little help ... I was following the upgrade process to move everything from my venerable old ISY994 to the shiny blue Polisy Pro, the Polisy showed up in the Admin Console after I used the Add button. Then I did <something> (sorry, can't for the life of me recall the menu item I selected), and Polisy did a bunch of things, then settled down to displaying just its left most LED. Looked totally normal. After that process, when I run the Admin Console from the desktop IoX Launcher, only my original ISY994 shows up. So I try to Add the IoP as before, but the Console just reports it can't find an ISY at any of these URLs, entered one at a time: https://192.168.1.23:8443/desc ... http://192.168.1.23:8080/desc ... http://192.168.1.23 I CAN enter http://192.168.23:3000 into my browser and get to the new Polyglot3 web interface, login in with admin/admin. The IoP ISY MAC was shown, and I was allowed to add the old ISY MAC to the ISY list. Everything else I do keeps telling meI have to "approve' the new IoP in the Admin Console. But if I can't get it to Add to the Console, I'm hooped according to the migration instructions: Connect to ISY on Polisy (IoP): Ensure Polisy is running and updates above have been made. No need to connect to PLM at this point, still in preparation stage. Open the ISY Finder and see if it finds Polisy. If not, Add the following IP addresses, one at a time: http://myPolisy:8080/desc and https://myPolisy:8443/desc, where myPolisy is your IP address of you Polisy. Once the Polisy is found, open the Admin Console (Cloud or Lan): [ etc etc ] I've tried everything I can think of to move forward, but I'm out of ideas: rerun upgrade, reboot Polisy, update Polisy, power cycle Polisy, push that teensy-tiny hard-to-see-with-my-aging-eyes button with a paperclip - JUST ONCE - to check my upgrades are complete, checked my network connection (its good, and I can ping the Polisy and it shows up on my router's wired connections with the correct IP4 and MAC), and on and on. I know the next step is a Support Ticket (Michael has been a GREAT help in the past). But I was hoping someone here recognized this chicken-and-egg situation and had a simple solution (like, maybe I missed something?). All input MORE than welcome.

This issue is resolved now, but it took a while to get here. Short version: The Polisy was running a pretty old release of FreeBSD, and also needed to be reflashed. If you're having a similar problem, submit that ticket and Michel and team will help you. Long version: I tried using USB-serial cable with serial input to get access to Polisy's software. Doing so seemed to unblock a huge queue of loggjammed updates (pretty sure that was my fault with my flailing). Once these cleared, I could ssh into Polisy again. At that point Michel suggested sending the unit back to UDI in California - but I live in Canada and I KNOW what kind of costs and delays crossing that border twice will be incurred. So I asked about some kind of remote login solution/reflash. Michel and his team worked for a couple days to log in to the deivce over the internet (GoToAssist, ssh, etc), but connections kept dropping. Finally MIchel suggested that, if I could dig up a mSATA to USB adapter, I could remove Polisy's 32GB SSD and use a downloaded image file to reflash the drive. That's the route we went - using an adapter I bought for a Raspberry Pi some years ago, I got the 32GB SSD reflashed in well under an hour, and when the newly flashed Polisy woke up again, it was fully functional (but the old configuration was gone - no surprise there, and that's what configuration notes are for). Polisy now reports it's running FreeBSD 13.1-RELEASE, Version 2.2.13, Frontend Version: 2.2.9-5, ISY Version: 5.3.4. When I run ISY Launcher, it now lists Polisy 5.4.4 under the ISY994 along with upgrade button. I have to go through configuration again from my notes, and then figure out the IoP migration, but at least its now possible. I am extremely grateful for Michel's help over the past few days - before he responded to my ticket, I thought my options were either to send the device back to the Mothership and not see it again for some weeks, or shelve/resell it and stick with the ISY994 until it was obsoleted..

Thanks Mr Bill - yeah, that's what I thought. But I figured asking the more experienced folks here was worth a shot, and that someone might recognize the symptoms I described and have a canned solution.

I've obviously borked the poor Polisy on my desk with my frustrated flailing ... No matter what I do - power cycle, poke it with a paperclip, plug and unplug the network cable from my network - it doesn't join the network, its not visible on the network (entering https://polisy into any of my browsers gets me an "Unable to Connect" response), and all it does is cycle through a REALLY annoying sequence of (facing front of unit where the LEDs live): - 3 beeps - then all 3 LEDs flash for 15 seconds - while that's going on, the ISY944 blue Memory LED flashes once, then a second later 2-3 times - then Polisy emits a "chirp", then left 2 LEDs flash for maybe 10 seconds - then all 3 LEDs go on solid for 5 seconds, after which middle and right-most LEDs go off - then left most LED stays solid for maybe 20 seconds - then its back to the top: 3 beeps, etc ... repeat, repeat, repeat ... If I can JUST get access to it again via browser or ssh, I should be good, but this thing is a black box (well, a blue box) when its misbehaving. Could use some help before I go mad from those 3 beeps (assuming its not too late). All I started to do was upgrade the ISY944/Polisy pair to IoP. ISY at 5.4.3 and Polisy at 2.2.13. I even dug into the back of my closet and actually FOUND (to my considerable surprise!) the serial cable that came with my 2413S PLM way back in 2017 !

Thanks, xKing - Will do !! Your help is greatly appreciated.

Thanks, xKing - that got me past that obstacle. Now I'm back to the original issue: my SE inverter models are 'SE3800A' and 'SE3800H', once your code truncated the -xxxxxx info. Suddenly they're reported as unsupported when they were working previously. Can you foresee any issue with me just adding 'SE3800A' and 'SE3800H' to the SINGLE_PHASE model set in the Polisy code, so that my inverters are supported again? I'm still not sure how they were considered supported with previous code which had the same SINGLE_PHASE set of models as v0.06. But previous to this update, they WERE reporting the same data to my ISY as the inverter displays were reading. [ Edit: I added 'SE3800A', 'SE3800H' to your SINGLE_PHASE model set, inserted just after 'SE3800' (I left that unchanged in case there IS a model SE3800), then started the SolarEdge NS. its now running normally again, reporting: 2020-04-23 17:58:03,590 [Controller] [INFO ] Updating Driver 277630 - ST: 0, uom: 73 2020-04-23 17:58:04,848 [Controller] [DEBUG] {'data': {'count': 12, 'telemetries': [{'date': '2020-04-23 16:58:09', 'totalActivePower': 2548.0, 'dcVoltage': 369.438, etc - BIG SNIP}}]}} 2020-04-23 17:58:04,851 [Controller] [INFO ] Updating Driver 7f12b562a8 - ST: 888.0, uom: 73 2020-04-23 17:58:04,854 [Controller] [INFO ] Updating Driver 7f12b562a8 - GV0: 89.5, uom: 56 2020-04-23 17:58:04,856 [Controller] [INFO ] Updating Driver 7f12b562a8 - CPW: 893.0, uom: 56 2020-04-23 17:58:04,858 [Controller] [INFO ] Updating Driver 7f12b562a8 - CLITEMP: 33.7139, uom: 4 2020-04-23 17:58:04,862 [Controller] [INFO ] Updating Driver 7f12b562a8 - CV: 241.359, uom: 72 2020-04-23 17:58:04,864 [Controller] [INFO ] Updating Driver 7f12b562a8 - GV1: 364.688, uom: 72 2020-04-23 17:58:04,866 [Controller] [INFO ] Updating Driver 7f12b562a8 - GV2: 3.7, uom: 1 2020-04-23 17:58:04,868 [Controller] [INFO ] Updating Driver 7f12b562a8 - GV3: 60.0, uom: 90 2020-04-23 17:58:04,871 [Controller] [INFO ] Updating Driver 7f12b562a8 - GV4: 2, uom: 25 2020-04-23 17:58:05,065 [Controller] [DEBUG] {'data': {'count': 11, 'telemetries': [{'date': '2020-04-23 16:59:54', 'totalActivePower': 3002.92, 'dcVoltage': 390.806, etc - BIG SNIP}}]}} 2020-04-23 17:58:05,068 [Controller] [INFO ] Updating Driver 731c2111c1 - ST: 2495.0, uom: 73 2020-04-23 17:58:05,070 [Controller] [INFO ] Updating Driver 731c2111c1 - GV0: 277.057, uom: 56 2020-04-23 17:58:05,072 [Controller] [INFO ] Updating Driver 731c2111c1 - CPW: 2510.34, uom: 56 2020-04-23 17:58:05,074 [Controller] [INFO ] Updating Driver 731c2111c1 - CLITEMP: 36.2592, uom: 4 2020-04-23 17:58:05,077 [Controller] [INFO ] Updating Driver 731c2111c1 - CV: 243.538, uom: 72 2020-04-23 17:58:05,080 [Controller] [INFO ] Updating Driver 731c2111c1 - GV1: 387.644, uom: 72 2020-04-23 17:58:05,082 [Controller] [INFO ] Updating Driver 731c2111c1 - GV2: 10.3, uom: 1 2020-04-23 17:58:05,083 [Controller] [INFO ] Updating Driver 731c2111c1 - GV3: 60.0, uom: 90 2020-04-23 17:58:05,086 [Controller] [INFO ] Updating Driver 731c2111c1 - GV4: 2, uom: 25 I only made this change in my own Polisy, I won't upload it to your github code as I don't fully understand the ramifications of doing so, and don't want to break anything for other people. Was there a deliberate reason to knock out the SE3800A/H inverters from the original code where they were considering supported? ]

Oops, not quite. Instruction <git branch --set-upstream-to=origin/master master> returns error: the requested upstream branch 'origin/master' does not exist hint: hint: If you are planning on basing your work on an upstream hint: branch that already exists at the remote, you may need to hint: run "git fetch" to retrieve it. hint: hint: If you are planning to push out a new local branch that hint: will track its remote counterpart, you may want to use hint: "git push -u" to set the upstream config as you push. Is there a typo in the instruction, or should I be running "git fetch" before re-running it?