[RELEASE] ST_Anything v2.9.7 - Arduino/ESP8266/ESP32 to ST via ThingShield, Ethernet, or WiFi

Dan,

The intermittent false indication I was getting was from using an external pull up resistor (10K ohm). I never noticed the default use of the built in pull up. Even when I changed the argument to false I still was getting the false indication, however adding the optional numReqCounts argument to the constructor with a value of 100 eliminated all the false alarms. I have bench tested a setup with the internal pull up and no counts argument and it works. Guess I should have read the associated comments. I’ve taken my original apart and I will rebuild with more functionality (smoke and motion).

Thanks

1 Like

@vseven
Holy smokes, that was weird. Okay, I think I figured it out. Thanks for the help! I switched the RGB Switch tile attribute, and that helped get more stuff in the logs. Watching the serial monitor, it looked like no matter what I did, the rgbSwitch1 on command wasn’t making it to the device. Here’s the on function from the child device handler:

def on() {
    sendEvent(name: "switch", value: "on")
    def lastColor = device.latestValue("color")
    //log.debug("On pressed.  Sending last known color value of $lastColor or if null command to white.")
    parent.childOn(device.deviceNetworkId)
    if ( lastColor == Null ) {  // For initial run
    	white() 
    } else {
        //log.debug "on event lastColor: $lastColor"
    	adjustColor(lastColor)
    }
}

And here’s a version that worked for me:

def on() {
    sendEvent(name: "switch", value: "on")
    def lastColor = device.latestValue("color")
    log.debug("On pressed.  Sending last known color value of $lastColor or if null command to white.")
    // parent.childOn(device.deviceNetworkId)
    if ( lastColor == Null ) {  // For initial run
        white() 
    } else {
        //log.debug "on event lastColor: $lastColor"
        adjustColor(lastColor)
    }
    sendEthernet("rgbSwitch1 on")
}

Silly me, I originally put the sendEthernet call right next to the parent.childOn call. However, if sendEthernet is not the VERY LAST THING in the on() function call, it doesn’t work. Even adding a log.debug after the last sendEthernet breaks things. I have no idea what’s going on, but it seems like things are working now.

Phew!

Edit: Looks like it’s not perfect. When the light is off and I set the level with the multi-attribute tile, it doesn’t work. The tile turns of, but the command never gets sent. Looking at the serial monitor again, it shows the adjustcolor command going to the device, but not the on command. Is there some restriction that says only one sendEthernet command can run per tile stat action or something? That doesn’t make any sense, but that’s what it seems like is happeneing.

The easiest way to start using the sketch’s callback() Routine is to simply uncomment the two Serial.print commands at the beginning of it. Then, fire up the Arduino IDE Serial Monitor window to watch exactly what is sent to ST. You can then add some logic to detect whatever events are important to you, and then take any actions desired.

I’ll look for an example and post here if I find a good one. If you can describe exactly what you’re trying to accomplish, I may be able to simply write a personalized example.

I recommend that you use at least 500 required counts to help prevent false events. You won’t notice the delay at all, as it is just 500 times through the loop() routine.

Glad to hear you figured it out!

Like i said, I’m trying to switch a relay when a contact sensor changes and then turn it off when it changes back.

Here is an example that should help get you started…

One thing to be aware of… every 5 minutes ST_Anythings sends updates to ST even if nothing has changed. These updates will also result in the callback() function being called. You may need to add additional logic (i.e. local static variables) to your sketch to be able to detect a change in state of an input.

It’s that simple? I dunno why I was thinking it would be a lot more complicated. Thanks!

1 Like

When you do a set level if the level is zero it sends the off command and if it’s anything above zero it sends the on command. I’m not sure if there is a limitation to how many times the send ethernet can run (sounds like there might be based on your testing) but if you’re already sending the level using that maybe the on-and-off aren’t being commanded afterword.

That was super simple (the callback function)!!! Worked like a charm on my first try!! Thanks Dan! :+1:

1 Like

I just got mine set up last night and seems to work pretty well. Thanks, Dan!

A very simple question, it seems… Is there a way to change the way the child devices show up in the parent device? For example, my temp sensor shows up as “temperature 1”. How do I change that? Renaming the child device itself doesn’t do anything. And pressing the “Configure” button in the parent device doesn’t seem to do anything but update device network ID and number of buttons?

def configure() {
	log.debug "Executing 'configure()'"
    updateDeviceNetworkID()
	sendEvent(name: "numberOfButtons", value: numButtons)
}

Thanks!

1 Like

I have never found a way to edit the child device names shown within the Parent Device. Since each child device can be renamed independently, and they all show up as individual things, I don’t find it to be much of a problem.

If you really want to, you could modify your copy of the Parent Device Handler code to uniquely name the child devices automatically when they are initially created. You’d need to have a unique Parent DTH for each of your ST_Anything devices. It would have to include a lookup of generic names to your specific names, and use those names when creating the child devices. Just do NOT change how the Child Device Network ID’s are created, and that is what is used for the keep those devices up to date.

I have a few esp32 boards, Wemos and Adafruit variety’s. None of them can connect if using the Recommended Static IP method. They do connect if using the router DHCP assigned method. Any ideas why? My esp8266 and ATWINC1500 boards connect fine with the recommended static method, only an issue with esp32

//Create the SmartThings ESP32 Communications Object, STATIC IP Assignment - Recommended
//st::Everything::SmartThing = new st::SmartThingsESP32WiFi(str_ssid, str_password, ip, gateway, subnet, dnsserver, serverPort, hubIp, hubPort, st::receiveSmartString);

//DHCP IP Assigment - Must set your router’s DHCP server to provice a static IP address for this device’s MAC address
st::Everything::SmartThing = new st::SmartThingsESP32WiFi(str_ssid, str_password, serverPort, hubIp, hubPort, st::receiveSmartString);

I have never seen that behavior, however I am not running any ESP32s currently. One problem with these devices is the rapid rate of change with supporting libraries. I do not test every device with every new release of supporting software. Sometimes incompatibilities do arise.

There are definitely some little issues with the ESP32 wifi. If you check the github for the software you’ll see a bunch. Even after adding in code to reboot the device after so many failed Wi-Fi reconnects I still have to manually reboot it every week or two because it loses its connection. Since for me it’s easy to do I haven’t gone through trying to troubleshoot it further. But I know that the code is constantly under development and last I heard they were talking about the revision to board to fix some of the issues with the current board such as analog inputs needing to be manually calibrated per input. Took me a lot of trial and error and testing to get my couple analog inputs working properly because of that issue (although they work great now).

I set a DHCP reservation on my router for its Mac address just to make sure it always pulled the same address and that seems to work fine. I did the same for my two Konnected panels also even though the smart app supports discovery. Just easier to have the reservations in DHCP and I know exactly what IP address they are at.

2 Likes

Doesn’t the ST_esp32wifi library have a “reset board” after a number of failed connection attempts, though I saw it in there. My WeMos Lolin32 board disconnects and goes dead everyday ~6:30am and reconnects sometime after 11am. It does a hard reset when comeing back up because it clears the variables stored. Its the weirdest thing, no idea why. I’ve cleared all the old IPs and settings in my router, router has no schedules set up, tried turning the board on late at night to see if it is a constant time thing… Always around 6:30am… My adafruit esp32 board does not do this but it does go dead at random times (2 to 5 days) and require a reset.

Yeah…it checks if its disconnected and tries to reconnect 10 times I believe and if it fails issues a reboot command.

1 Like

Static IP issue is noted on GitHub:
ESP32 does not accept Static IP #1262

1 Like

Sounds like the devs broke the Arduino ESP32 board support package. Hopefully a permanent fix is forthcoming soon.

I’m having trouble figuring out how to use the send() function to directly send a string to the ST hub. How do you format it correctly?

You’re going to need to provide a few more details, please…

If you’re trying to send data from within a typical ST_Anything sketch, you can simply call the sendSmartString() function as shown below.

If you are just using the “SmartThings…” libraries from my GitHub project, you can choose to send whatever strings you desire. You’ll just need to process those messages in your own custom Device Handler’s parse() routine. I included Ethernet and ThingShield Device Handler examples within the SmartThings library’s ‘extras’ folder. These are basically the original SmartThings On/Off ThingShield example retooled slightly to work with my version of the SmartThings library. Ethernet support was added in early 2017.

1 Like