@tim.ocallag, so happy this idea worked out for you, too bad I won't be able to further this project with the scale, 
1 Like
love this - ingenious and inexpensive !! going to Walmart to buy plastic food containers - wife will be so proud of me (but little does she know...) !!
Does anyone have a good example of an Executor sensor being used in ST_Anything... I want to send data from a Hubitat device to my ST_Anything to be processed with other sensor info.....
Ive played quite a bit with poll-able and interrupt sensors but am a little confused on how the mechanics of the execution sensor work, for my use case above..
Thanks for any help, in advance..
Executors are designed to only receive commands from the Hub. For example, a EX_Switch device simply sits around waiting to receive an 'on' or 'off' command from the Hub.
So, the real question is... What are you trying to accomplish? Please explain in detail your requirements and I will explain the best approach to achieving your goals via HubDuino/ST_Anything, while staying within the architecture.
In fact, I am still waiting to hear back from you regarding the following post...
Dan thanks for the quick response..
Your previous response and advice on Ultrasonic 1&2 devices, worked beautifully! I was tweaking things all weekend.. and now have my ST_Anything device with Ultrasonic + Temp + humidity data - all being processed with the answer being sent back to the Hubitat device - where Webcore picks it up and acts on it !!
So what i'm now trying to do is the following..... I have 1 ST_anything device with Ultra and temp/humid sensors (the distance is calculated with Ultra + Temp+humid) .. I have a completely separate St_Anything with another Ultra but i wanted to use the Temp/Humid from the first ST_Anything.. So I wanted to pass temp/humidity data from one ST_Anything to the other, via Hubitat..
Was thinking I could use an Executor sensor to do that Hubitat to ST_anything communication.
Why not just add another temp/humidity sensor to the second microcontroller, and use the exact same method as the first one? Seems like a much simpler and more robust solution. ST_Anything was never architected to act the way you're proposing...
ha yes !! one would say i'm being cheap !! although i wanted to play with ST_Anything device communication.....
so absolutely agreed, simply add another DHT-22... but wanted to experiment with MC to MC comms....
Yep, I hear ya... It's just supported via the current design of HubDuino/ST_Anything. There are ways one could hack things together, but traffic would still be flowing through Hubitat.
yeah - thats where my mind was going .. MC#1 to HE, HE to MC#2 (using executor sensor or something)... i assume that would be the hack..
Ok, now we're getti9ng down into the depths....
If you want to 'intercept' a message that is sent from the Hub to the microcontroller, then add the following to your sketch...
add a new callbackRcvd2() function to the sketch, in addition to the callback() function.
//******************************************************************************************
//st::Everything::callOnMsgRcvd2() optional callback routine. This is a sniffer to monitor
// data being received from ST. This allows a user to act on data changes locally within the
// Arduino sketch before ST_Anything processes the command.
//******************************************************************************************
void callbackRcvd2(String &msg)
{
//get the message from Hubitat before it is processed by st::Everything.
if (msg.startsWith() == "temperature") {
//Do something
}
if (msg.startsWith() == "humidity") {
//Do something
}
msg = ""; //we don't want st::Everything to do anything, as we should have processed the data above instead.
}
within setup(), add the following code.
from
//Initialize the optional local callback routine (safe to comment out if not desired)
st::Everything::callOnMsgSend = callback;
to
//Initialize the optional local callback routine (safe to comment out if not desired)
st::Everything::callOnMsgSend = callback;
st::Everything::callOnMsgRcvd2 = callbackRcvd2;
Hopefully this will get you started... you're on your own from here... 
thanks Dan... appreciate it..
I hope someone can help; I'm a 62 year old that muddles thru. I've created various Motion detectors on ESP-WROOM-32 boards that have integrated successfully on my HE network using - ST_Anything_Multiples_ESP32WiFi.ino .
I'm struggling with a controller for RGB using the Arduino sketch -ST_Anything_RGB_ESP32WiFi.ino ; it has this history (is there a newer version?):
I've used the same SSID and once uploaded and restarted my network sees the new IP Address; When I have created the device in HE and saved preferences it does it's normal thing but fails with this:
I believe its using this Driver:
So I'm not sure if the error at line 412 is my coding error or a hardware error (although same situation on 2 ESP boards)
Could someone point me in the correct direction - I've been backwards and forwards through the forum but getting nowhere,
1 Like
@ogiewon
Just wanted to ask if this is normal. I updated my sketch which I used on ST side to control my blinds. Changed ip address and port. Then installed all drivers from your drivers list...blaa blaa blaa...
EDIT: Ditched old ST used sketch and changed it to one of the example sketches in your github. Blinds are now working. Thanks @ogiewon for building this stuff to our use!!
Parent found two child servos for some reason and number 2 is the one I'm using. Not sure what does that mean but going to learn
If the example sketch you chose to use has two EX_Servo devices defined, then yes, you should expect to see two child devices.
You can edit the setup() portion of the sketch, and comment out the extra EX_Servo declaration, as well as the section of code a little lower in the setup routine where that executor is added to the Everything class.
After doing that and updating the microcontroller with the new code, you can simply go into the extra child device on your hub and remove it.
1 Like
@ogiewon i'd just like to say thank you. not only did you set up this amazing driver, but you're also helping people with their sketches (which is technically outside the scope of hubitat). you are truly an awesome person
4 Likes
Hi Dan @ogiewon - just a very quick question, please - Am I fighting a losing battle trying to get that RGB sketch working (ST_Anything_RGB_ESP32WiFi.ino)? Or should I persevere?
Thanks in advance.
To be honest, I really don’t know. This particular device was added by a SmartThings community member. Thus, I have never used it, and cannot say definitively if it is worth your time or not. Wish I had better news for you.
Thanks for your reply anyway @ogiewon . Think I need to go back to basics and try to work out what all the elements and integrations between the sketches and the HE parents & child drivers do.... before expecting to debug my setup.
Hey @ogiewon -- just want to pile on with the kudos for both the technical accomplishment that is this mini-ecosystem and for your generous encouragement and support to those of us using it. (Followed you here from ST.) I just got my first ESP8266 Hubduino working this weekend to spoof closure of a momentary pushbutton that turns on my mattress warmer and it's been VERY fun. Thank you!!
Question about next project (apologies in advance if this is well trodden ground since I can't imagine I'm the first person to try this... but I haven't turned up much despite a diligent attempt):
I'm looking to use a rotary digital encoder like so to create a dimmer control (just want to send Hubitat brightness adjustments). Given that it's a pulse device, I was thinking pulse_counter, but I need something that acts like an InterruptSensor...
- Would you recommend adding a hardware interrupt handler, etc to an InterruptSensor sketch or modifying pulse_counter to send a spontaneous update after the encoder position is moved? (Or maybe beyond the Anything library scope...?)
- I understand I need to be careful to make everything about reading the encoder non-blocking... are there other ST_Anything-specific gotchas to be aware of in implementing hardware interrupt handlers?
edit: I forget that the CPU on the ESP8266 is so much faster than an Uno... based on a little experimentation I can almost certainly get away without interrupt handlers, but curious for your opinion in any case.
Tagging @tim.ocallag as well since this has some similarities to your cadence sensor.
Looking forward to contributing to this community!
-tim
This is not a super simple one to figure out the best architecture to implement. If I were going to attempt this (and note, I personally recommend using a Lutron Pico remote instead!) I would try to find an ABSOLUTE rotary encoder, as that will always provide the same value at each rotational position. I would then try to implement it in a manner similar to the Lutron Aurora zigbee device (note, this is another option that you can simply buy, off the shelf, and does not require the Lutron SmartBridge Pro), where is basically emulate a smart dimmer device, that you could use to have other real devices mirror/follow its attributes.
Interrupt handlers are a good choice to try to capture a high frequency stream of data. However, you still have the challenge of trying to figure out at what frequency you can reliably send updates to the hub, so as not to overwhelm it with network traffic.
Implementing an IS_Button device would be much simpler, and can easily be integrated with Hubitat's many apps that can handle button controller devices. This is the way I would go if I were going to attempt to build my own button controller device.
