Just checking in to say my hub is also running on 027.006 and my ESP8266 devices are still sending data. I know that doesn’t fix your problem, but I wanted to add a data point–it doesn’t seem like a blanket problem affecting all devices.
I have the same issue since today. I do have a relay switch that should only energize for 500ms. Now it only works very sporadically, doesn’t log anything anymore and energizes for many seconds. If I remember right the 500ms value was in the microcontroller code. I don’t understand what ST is sending now that causes so many problems. The application has 2 modes, like a short 0.5s signal and a long signal 3s. Now it only activates the wrong thing. This was working great for over a year at least. Why ST why?
I’m trying to get some more debugging messages in the code… Looking in the right place now, thanks to Dan.
I’m having the same issue as others. Not reporting sensor values, the outputs work, but very sporadically. The devices show up in the logs but not the sensor values. I also have another hub at a different location and it seems to be working fine.
Looks like the recent ST Firmware update is preventing unsolicited LAN Messages from being received and processed whatsoever. This is broken for both ST_Anything and OmniThing. Not sure what was changed by SmartThings. I recommend everyone ask SmartThings to explain what changed. The more users that report the issue, hopefully the more attention it will receive.
Perhaps posting the issue in the following thread might receive attention?
OK I posted there – everyone impacted should please +1 here: Hub Firmware Release Notes - 27.6
Do we know of other SmartApps that use unsolicited LAN messages? This must have broken other things…
All - my son and I are looking into this issue, however as of right now, we don’t have any idea of how to fix this, except for SmartThings to correct the firmware on the hubs.
Both ST_Anything and OmniThing continue to work without issues on Hubitat (where you choose if and when to update the hub firmware…and have the option to rollback firmware if necessary.)
While I’m not using the parent-child paradigm, all of mine are sending data to the hub successfully.
What type of micro-controller are you using? What is the communications mechanism, LAN/WiFi or old ThingShield?
@ogiewon ESP8266, ESP32, and some old ThingShields (which are zigbee). LAN/WiFi
The ThingShields should be unaffected. It is just the LAN/WiFi devices that are having problems. And, it is not isolated to ST_Anything… Check out all of the other integrations that are now broken in the Firmware 27.6 thread…
My LAN/WiFi devices (ESP8266/ESP32) are working. I just thought I would share in the event it helped you figure it out. Maybe it is shard related. I don’t know. I saw that it broke a lot of things. I do know that the Samsung Smart Appliances only work correctly in certain locations. Good luck.
SmartThings has acknowledged the LAN communication issue in the 27.6 hub firmware. They have posted a workaround that you can try until they can implement a permanent solution. I tested this and my ESP8266 can now send updates to ST.
I just gave it a try, waited for the blinking LED, but still no sensor data
Wonder why yours came back but mine not, I’m on na04-useast2.
I give it another try, until I receive a message from ST about my hub being offline.
I did not wait that long, just 30 seconds on my v2 hub. I did also restart the ESP8266.
OK, got both ESP8266 back online and also the one sensor created the child device.
Took me a few tries and finally timing it with a stop watch did it.
Back to the drawing board and fix my broken automations
The workaround is working on my V2 hub for me too.
Dan, any idea why the relay switch that in normal operation works with 500ms with the bug present holds the contact much longer (probably3 to 5 seconds)? I thought the timing code did only execute on the esp8266?
Assuming you’re using the TimedRelay device in your sketch, all of the timing is performed locally in the ESP8266. Have you tried restarting the ESP8266 to see if it’s performance improves?
Yes, I tried many power cycles. At first I thought my esp8266 was going bad. I’m using the TimedRelay device and it really baffled me because I remembered that I hard coded the timing and it just worked until this bug happened. Btw, thank you very much for creating this project. I have the esp8266 hooked up to two buttons of my bed frame remote. A short push on button 1 executes the preprogrammed bed position and a long push programs the position the bed is currently in. With the bug it mostly programs the flat position to button 1. Plus the lights on the remote turn on when the button is pushed and flashes differently depending how long the button were pushed. This indicates that it doesn’t release in time. The other button is the flat button and this one only has the long push option. I don’t have button 1 on the esp8266 programmed for a long push, only the flat button is long. But now with the bug all buttons behave like the long timing. Maybe I did something wrong when I modified the sketch one year ago. To be honest I don’t know where my code is right now, quick question: did something major change on this sketch that could explain this? Should I recreate it and load it again? As long as ST fixes the bug it works good, so I probably just wait it out by using the workaround. I just need to remember that I’m using this workaround and this can be difficult if ST takes a long time to address this.
The work around brought my contact sensors back, but now I can only send an open command to my garage door, close no longer works.