maxnorth

I should have said that the temp sensors ARE available as Status in programs. If a temp changes, I can detect it. Not true for switches.

Ok, I've had a chance to test the MQTT Explorer solution: 1. Delete MQTT nodeserver 2. Using MQTT Explorer, delete all in tele, tasmota and stat folders (not $SYS). 3. Reinstall MQTT in same slot Result: Status of all devices IS now updating in AC. This includes switches and temp sensors in my case. (Good work, guys!) Can confirm: These devices are available in AC programs as "Control" but not "Status." Perhaps unrelated, but adding to radar: My sole "type:s31" device is not available as either Control or Status, so is unusable in programs. See this earlier thread, which received no response:

I had explored this somewhat in a previous thread: There are a couple of paths listed in there that might be helpful.

I won't be able to test the MQTT Explorer solution til tonight. Personally, I'd also be interested in using the SSH solution if you can tell me which files should be deleted. Seems like a more robust solution for a clean install.

I'm up on MQTT Explorer, but not sure what exactly needs to be deleted. See screenshot

We will have to wait for the devs to make it available in the store, I believe.

v35 was stable for me.

None of mine are updating, including switches and temp sensors. I have rebooted eisy several times in the process, both before and after the reinstall. MQTT debug log attached. I MQTT_4-23-2024_21205_PM.zip

I just tried again: delete and reinstall the nodeserver (0.0.37) in the same slot. No change. I can control the devices but the status in the AC does not update. For what it's worth, I am using a devlist, not a devfile. I made no changes since the prior version, which was working.

For what it's worth, I installed 0.0.37 and now I have the same problem you do. I can control devices but the status in the AC does not update. Any clues @TriLife?

I reinstalled 0.0.37 from the store and now it starts fine. I can control all devices fine. But the status of the devices no longer updates in the AC.

A clue from the PG log file: "error: updateNs: Node server MQTT has no store entry in Production." But MQTT does appear in the plugin store.

Just updated my eisy using "Upgrade Packages." My other node servers are working fine, but MQTT is not. It does not start. When you click on Start, Stop or Restart, it displays a red error message that "Update check failed" and it does not start. I don't know what that is, but it seems odd that a failed update check would prevent the existing version from starting. I'm on IOX 5.8.0, PG 3.2.22, and MQTT 0.0.35.

Well, one device is working, so that suggests the issue may be with the config of the clients. Let's review: - You are using Tasmota, I assume - You have logged into the Tasmota web interface for each device and configured it correctly, especially the "Configure MQTT" menu choice. (Be sure to type in the password even though there appears to be one there already). - If so, you should be able to look at the "Console" menu choice in the Tasmota interface and see the MQTT messages being published by Sonoff. When the device is turned on or off, you should see a properly formed MQTT message. Its format should match the format you've specified in the dev list for stat/ and cmnd/, in particular the device name should match. Capitalization should match. - If there is a mis-match, it does not throw an error. Just nothing happens.

Pick one of the offending devices, delete it from the node server (both as a node and from the dev list). Then re add it to the dev list and try again. Once a device is added to the node server, it stays there until the node is deleted, so this will ensure a fresh start. Just test on one device first.

Try using all caps POWER in your command topics.

I have had similar issues on a one-off basis since my migration. Naturally, you think the program is not working, at first. But, as it turns out, I have been able to resolve all of my issues so far by just restoring the device. (Highlight, right click, restore device).

@xKing, I have had no takers on this question. The power sensor device (s31 in dev file) simply does not show up anywhere in programs. (Sonoff temp sensors DO show up). I'm on the latest PG3 and 0.0.35 of the node server.

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.