maxnorth

I had this posted in the PG3 MQTT forum, but the more I think about it, it is not a polyglot issue. The nodeserver seems to working fine. I have flashed a Sonoff s31 (not Lite) with Tasmota and added it to my PG3 devfile using the "s31" type as described in the MQTT configuration help. It's brought into the admin console fine and all the energy values display in the console as shown in the attached screenshot. However, I am unable to "find" the device (control or status) when creating programs. In other words, I cannot use any of the values for anything. The device, in this case named sSonoffs31POW, does not appear in the control or status list in programs. (Other, non-energy Sonoff devices appear fine). The icon for the device in the device list shows two cute red and blue arrows flying off the device, which I have not seen before. Does this mean it is detected as an energy management device? Is it possible I am unable to access it in programs because I do not have the UDI energy management module? Is that even available? Any other ideas?

I have a number of 8 button KPLs that work fine. I have installed my first insteon 6 button KPL and have issues with the backlighting. This KPL has an On button on top and an Off button on the bottom, but the admin console only shows a single entry for this load, not separate entries for On and Off. That is fine. Two issues: 1. When I set the backlight for this load to On 6/Off 0, for example, the On light comes on when on and the Off light comes on (at power 6) when off. In other words, I can find no way to make the Off button stay dark at all times. The exception is if I set it to On 0/Off 0, then neither the On or Off light ever comes on. That is livable, but not ideal for me. And this leads to the second problem. 2. With this KPL, if I set the backlight level for any button, it affects ALL buttons. As I recall with the 8 button KPLs, each button's level could be set independently. That is not the case with this device? Is this a known issue?

Because the wiki (https://wiki.universal-devices.com/index.php?title=ISY-99i_Generic_Calendar_Using_Programs_and_Variables) suggests that Sunday is 7 and there is no zero value. But perhaps I am misreading something: "iDay.of.Week starts with 1 on Monday and counts through to 7 on Sunday. This variable is used to cross check the status of the variables against ISY’s internal day of week function so as to alert you if it gets out of sync. You do not need this variable since ISY has this function built-in but you can choose to use it instead of the ISY’s built-in day function and get the same result"

Well, what does your system show right now? It is Tuesday, and mine shows 2.

Current Day is 0 instead of 7.

Current Day of Week is 1 this morning, so it is reporting correctly. Seems like this was just a DST anomaly. Still seems strange that it would still be at 0 yesterday even after a reboot.

I have a slightly different problem. I have rebooted and all is well. Datetime on my eISY is correct. But my "DST Reset" program did not run last night (It is intended to restart all the programs that are supposed to run on startup). That reset program uses, among other things, the system variable "Current Day of Week" to trigger. (It is supposed to trigger at 1:15 am on a Sunday, which is day 7). Valid values are 1-7. That variable in my system is currently 0, not 7. The init value is also 0. The program did not trigger. Other date-related system variables, such as Current Month and Current Day of Month, are correct. But not Day of Week. This persists even after reboot. I was going to wait to post until tomorrow, to see if it would change to 1 on Monday, but thought I'd get a head start on it here. I will post an update in the morning. I don't know if this has been broken for some time, or if it's a DST anomaly.

Thanks, everyone, for the input. I am happy to report that this is resolved. I must have taken an extra dose of stupid pills at some point in the last couple of years, because the resolution was to pay attention to the font case of the topic specification in my devlist. At some point in the past, all of my devices had their "status_topic" changed to use lowercase "power," for example: "status_topic": "stat/sonoffbr2c/power." The correct usage is "status_topic": "stat/sonoffbr2c/POWER." So the Sonoff devices, although they would respond to a cmnd, they would not properly publish their stat topic; hence eisy was not updating with their current status. I discovered this thanks to some testing using mosquitto_sub (which is built in to the eisy Mosquitto implementation). To close out this thread, here is a summary for new eisy users: 1. Eisy contains an extra instance of Mosquitto available for use by the MQTT node server. You do NOT need to set up a separate instance as is specified in the original installation instructions for the node server. See above for reference to the gen.mosquitto.ud. This uses port 1884 and does not require authentication (no user or password required). While you could try to change the authentication config, I did not do so. 2. No change to the configuration of the gen instance is needed to run the node server, but use the IP of your eisy and port 1884 in the config for the nodeserver. 3. Since the node server does "require" a user name and password, go ahead and add the mqtt_user and mqtt_password Custom Parameters in the nodeserver config. You can fill in anything in these fields, or leave them blank, but the keys are needed for it to start correctly. 4. Note that I had a problem where the Configuration Help was not displaying on the node server configuration page -- UNTIL I added a Custom Parameter, then it showed up. This makes it exceeding difficult for a first-time user. I have attached a screenshot of the help text for new users. 4. On the sonoff device MQTT config page, which you access using the device's IP address, same thing, leave the user name and password blank, or fill them in with anything. Use the IP of the eisy as the host and port 1884 on the MQTT Configuration page. 5. Make sure the "Topic" you enter on the sonoff device MQTT config page matches the topic specified in your devlist. 6. Make sure the "Client" name on the MQTT Config page of the device is different than the Topic name. 7. **Most importantly**, pay attention to case in your devlist when setting topic names The below works for me (you would insert your own topic in the middle): - "status_topic": "stat/sonoffas6_a/POWER" - "cmd_topic": "cmnd/sonoffas6_a/POWER" 8. If you want to view the MQTT activity in the MQTT Nodeserver log, set the logging level to "debug," not "info."

Thank you, @Michel Kohanim. I can see the service at usr/local/etc/rc.d and have reviewed the config at /usr/local/etc/udx.d/static/gen.broker.conf. This confirms it is a broker running on 1884 and allows anonymous connections. Interesting, because the polyglot MQTT server (and the sonoff device config) requires that a user name and password be configured, although it may be ok for those values to be null. What I have not yet tried is adding a user and password to gen.mosquitto, then adding that to the node server and the sonoff devices to see if perhaps that will make a difference. The eisy still does not display the status of the sonoff devices.

Thanks. That command is not working for me. Is mosquito.gen documented anywhere? In the meantime, I've installed an eclipse broker using docker on my synology NAS and it seems to connect fine. But the status of the devices is still not updating in the Admin Console.

An update to my post. See this post prior to Michel saying "our next build will have two instances': It concludes with: "Update on what I learned from UDI support. MQTT is installed, however PG3 and PG3x make use of a private MQTT broker for internal communication between the various components, and that package is specifically configured to support PG3x. They advised I should just use another mqtt broker on another device on my network, so I used a broker on my Raspberry Pi that is for a different project, but is now serving two purposes." So, my question is whether this is still the recommendation with a new eisy and PG3. Is it necessary to install yet another MQTT broker for this node server? I now have the MQTT node server configured to point at the eisy port 1884 for the broker. And I actually get a success message in the log "Poly MQTT Connected, subscribing." And I can connect to the MQTT broker (no user or pw required) using another MQTT client. And the Sonoff device also shows a connection. But commands are not going through, so I suspect the broker is still "private" whatever that means.

I was a long-time user of MQTT for Sonoff devices on PG2. Recently upgraded to Eisy and PG3. In the old days, running PG2 on my Pi, we had to configure a MQTT broker on that device, and I used port 1883. With Eisy migration, I did nothing with a MQTT broker. I just installed PG3 and then installed the MQTT node server. It is not working for me as expected. The installation instructions for the MQTT poly suggest that nothing more is needed, but that does not feel right. Devices turn on, but they do not report back their status. The devlist is identical to what I used with PG2. I am guessing that there is a piece to configuring the MQTT broker that I am missing, and I cannot find any documentation about it. In May, @Michel Kohanim said "In our next build, we'll have two mosquitto instances running." That is interesting, but I have no idea how to configure either one of them, and can find no documentation on that. Question: port? user/pw? is the user/pw integrated with the eisy? is there a script to set this up properly? My current config is using mqtt_port=1844 and mqtt_password is using the password I have set up for each sonoff device (and had set up with MQTT on PG2). I have also tried admin|admin and the user/pw I use for Eisy. It seems to make no difference what I use, as I get the same number (14) of sonoff devices being added to the PG3 instance in any events and no change in the communications. Nothing meaningful shows in the PG3 MQTT live log. When I download a log, though, there are some entries, attached. I feel as though the broker is not working as it should to process return stats messages. This poly by @xKingis great when it works, and I'd be happy to help create some actual installation instructions for others, if I could figure out what I was doing wrong.

When starting a backup, I don't understand why the "create backup" command is labelled "move." I've never seen anything like that. And why is there no "success" message after a backup completes? There is no way to tell that you completed it unless you go to the folder and look for it.

Thanks, Bob, for pointing out my error. And then updated GV10 values are not showing in the log because they are not different than the previous values. Thank you!

Screenshot of unsuccessful and successful GV10 updates

Thanks, Bob. This is very helpful. A couple of remaining points: 1. When EPA AQI is recalculated, which should happen each time GV0 changes, should I also expect to see the updated GV10 value in the log at that time? I don't. 2. My EPA AQI values are not always correct, either not updating when they should or miscalculating (I don't have enough data to tell which). Example: Over the last few cycles, I've seen PM values of 2.3, 2.4, 2.7, and 3.3, all with an AQI value of 12 and none with a GV10 value in the log. The correct values are 10, 10, 11, and 14. Just now, the PM value updated to 2.6 and I finally saw a GV10 value in the log of 11, which is correct. So, I guess my suggestion to you is that GV10 is not updating reliably when it should be.

Bob, I've just got a new eisy and PG3 up and running and am trying to decifer how this is working. I have previous experience with the PurpleAir api and calculating AQI myself using PM2.5_10minute. A couple of questions: 1. On startup, the server retrieves and sets the values for all variables (e.g., GV0-GV12). But I notice the log for the server does not report the updating of all values for each subsequent 10-minute polling interval. For example, it might report only GV0, GV3 and GV4, or something. I have tried it with different sensors and get similar results. Comparing this to results I get when I poll the api directly, it appears that your log is only reporting values that are updated/different than the previous values. Is this correct? I ask because my log also shows "error sensor: poll:loading stats" at each poll. I want to make sure it is operating as expected. 2. Are you pulling the stats only from the "stats_b" dictionary returned by the sensor? 3. The "EPA AQI" stat, or GV10, is not returned by the sensor but is calculated by the node server: Is that correct? I assume the calculation is derived from the PM2.5_10minute stat. What can you share about the calculation?

Overall, my upgrade experience was fine and I found the migration documentation to be fine. A few points to be aware of: - If you want the IP address of your EISY to be the same as of your ISY, as I did, then you might want to make that happen before doing the migration. In my case, I use static mapping in my Ubiquiti router, so I deleted the old mapping and added a new one using the mac address of the EISY. The EISY admin console itself does not permit static mapping anymore, but this worked fine for me. It's just more difficult to do it after the migration, as there will be more reboots and anxious moments. - I did not realize that the EISY now forces you to use port 8080 for http access to the unit rather than port 80. Unfortunately, I have numerous outside integrations using REST and such that all needed to be changed manually. For example, from "http://10.20.30.xx/rest/programs" to "http://10.20.30.xx:8080/rest/programs". - I did not realize that the EISY would break my integration with Homebridge, in which I used the ISYMaker and isy-njs plugins. This means it also broke my integrations with HomeKit and HomeKit automations. (And when a HomeKit device goes missing, a HomeKit automation using the device is automatically deleted, so it's a real pain to recreate them). These plugins simply would not work for me (and they are no longer being supported), even after changing the port to 8080. I am now implementing Home Assistant instead. So far, I can do everything I need to do in HA, and it's actually better in some ways as others have pointed out on this forum. - The experience with PG3 has been good. In many ways, I even prefer the experience with the Elk server to the old integrated experience. However, I was on an old version of PG2. So, migration was not available -- no problem. But delete your old PG2 servers before you install any PG3 ones. Also, PG2 authentication was not integrated with ISY, as it is now for EISY. So, your old PG2 password may not work on PG3. Use your EISY password to log in to PG3. Magically, many of my polyglot devices were preserved in the transition, in my programs, which reduced the editing task. - Be sure that you first do an export of all of your programs into a text file. This made editing programs for replaced devices so much easier. - A minor pain updating the network resources. Click on them to open in edit mode, then click save, then click save again at the bottom of the list of resources. I did this for each one just to make sure each was saved after I opened it. That was all that was needed.

Edit: This has magically started working again for me. No errors. Both LAN and Cloud options.

I am having the same problems. Cleared the java cache, all three boxes. Downloaded fresh start.jnlp. I am getting the "not found" error but am unable to open the admin console even though it displays my ISY. I rebooted the ISY, no change. I can log in to the admin console over the portal, and UD Mobile seems to work fine. I had not logged in to the admin console in several weeks, so I can't say when the problem might have started. MacOS

Thanks! Now that I know it's an issue, there are a number of simple fixes.

My ISY994 time adjusted fine to DST. But I noticed that all of my running programs stopped running. I have a number of programs set to run on startup and they were not running anymore. Most of these are of the "repeat every x minutes" formulation. Perhaps that is thrown off by the DST change? Perhaps there is some other cause, but it seems too coincidental that is happened at this time. A simple reboot fixed it.

I appreciate all of your efforts. Looking to make the move to Polisy and PG3 soon.

So, to summarize: PurpleAir will no longer work on PG2, but the PG3 version works with their new servers. Is that a correct statement?

I've been running the Purple Air node server on my RPi for the last year or so, flawlessly. PG version 2.2.1. About a week ago, it stopped connecting, with no change in config on my end. ("Connection issue: <Response [500]"). My understanding is that this is an issue on the Purple Air server end. If so, are others having the problem? (I've tried it with multiple sensors) If not a Purple Air server issue, is there something else going on, with PG2 being deprecated? I don't even see Purple Air listed as a PG2 node server anymore.