Allan,
Sorry for the delay on the GitHub Pull Request response. I lost the main Router to the house a few days ago and have been busy trying to get that fully replaced/restored as well as working on my daughter’s car. I should have more time to focus on ST_Anything now.
Dan
No biggie. Gonna close some and replace with others. Been slowly modifying them to be closer to standard ones like adding preferences to the humidity and temperature to do offsets if the sensors are off, added a lot of labels to the contact sensor so it can be used for almost anything and have the displays correct, etc. Again they will need to be tested fully but I’m not sure why they wouldn’t work.
Sounds good. Let me know when you’re done with your changes and I’ll start the review process. I like the idea of a “Last Time Updated” tile. Always good to know.
Should be done…PM me with any questions although I’m sure you will figure it out.
Also the “Child IlluminanceRGB Sensor” is kinda a hack but it seems to work. Got my sensor today and it reads correctly using it.
Ken and James,
I used this guide to learn how to build a ESP01 programming circuit…
Thanks - I might just buy the programmer thing, that is a beast of a tutorial!
What’s the best way to power an ESP01 after it’s ready to roll?
James,
That’s a great question. I have only used it on a breadboard as a proof of concept solution. You’re going to need a decent 3.3V power supply with at least 500ma+ to make sure the ESP01 has a nice steady supply of power, especially when transmitting WiFi signals (current spikes during transmit.) Also, lots of tutorials online mention adding a capacitor to help with the peak loads to prevent the voltage from dropping too much.
Dan
Thanks, I like it because it’s so tiny and I’ll only need 1-2 inputs. But in practice I’ll probably end up using the bigger boards more often, just cause they’re easier to get up and going.
BTW, where is there a description of the parameters for devices? PS_Illuminance sensor1(F(“illuminance1”), 60, 20, PIN_ILLUMINANCE_1, 0, 4095, 0, 10000);
All of the “documentation” for each ST_Anything class can be found at the top of the respective .h and .cpp files.
So, for the PS_Illuminace class, just open up and look at the top of the PS_Illuminance.h file which can be found in your …\Arduino\Libraries\ST_Anything folder.
Change the last four parameters of the constructor (the 0, 4095, 0, 10000 values) to scale/calibrate the illuminance values sent from the microcontroller to SmartThings. Note: The first 2 values (0,4095) are the raw analog input values from the analog to digital converter. The second 2 values (0, 10000) are the corresponding LUX values sent. Check out the Arduino map() function for a better understanding.
https://www.arduino.cc/en/Reference/Map
You can use these parameters to force the “200” you’re seeing when totally dark to whatever value you’d like.
Note: the 0 to 4095 range is only valid when using a 12bit ADC (like found on the ESP32.) Regular Arduino baords and the NodeMCU ESP8266s have a 10bit ADC. Thus the fiest 2 values should be something like 0 to 1024.
Dan
Ah, the adafruit feather board shows the lux values max out at 2500 (when I shine a flashlight on it). Maybe due to the mismatched map scaling?
Yes, if you’re using an ESP8266 based board, be sure to set the range to 0, 1024 as I mentioned above. This will then properly scale the analog input range to whatever lux range you desire.
Todd,
Looks like Allan has implemented code to support your Adafruit sensor. Not 100% sure if it currently meets all of your needs yet, but it is a good start. I have not confirmed this code to work (as I do not have the necessary Adafruit sensor) so you’ll want to give it a try.
Please get all of the updated and new device handlers upgraded in your SmartThings IDE via the GitHub integration. Also, remember to “Publish for Me” all of these updates.
Next, grab the new Arduino code from Github as well. There is a new class implemented by Allan which should be pretty self-explanatory. I am sure Allan can provide some pointers if you have any issues.
Thanks Allan (@vseven ) for all of your work on ST_Anything!
Dan
I have tested and released (i.e. Github) @vseven 's code which allows code to be executed inside a Child Device Handler prior to updating the device’s value. In every Child Device there is now a “generateEvent()” function which usually just calls the normal sendEvent() function. Feel free to tweak this routine as you see fit for your application. (Note: Temperature and Humidity Child Devices already permit changing an offset parameter to help calibrate your sensors using this new capability.)
Please upgrade all of the ST_Anything Device Handlers (Parent and Child) in order to use this new functionality.
Thanks Allan for your work on this!
Dan
Am I correct that I need 1 parent dth for each board?
Yes, one Parent Device must be manually added for each board.
Note: The same Parent Device Handler code and Child Device Handler code is used for all of your boards. No need to replicate the code.
Got it. Awesome, everything is working great. Someone above mentioned doing a ‘sleep mode’ type thing. Could this be done with webcore at all? For instance: If smartplug power rises above 10W, then wake up nodeMCU…
James,
Can you explain what you’re trying to accomplish? Usually when people refer to a sleep mode, it involves a power savings mode which requires a specific amount of time to expire, or possibly an external digital input to be triggered, before the microcontroller will wake back up, perform a quick task, and then go back to sleep.
Based on my understanding of sleep, I do not see any simple way for WebCore to wake up an ESP8266 board since the ESP8266 will not respond to any WiFi signals while it is asleep.
If you describe the specific use-case, I am guessing someone will chime in with some options for you to consider.
Dan
Ah, well it may not be necessary. I’m using a photosensor to read the status of an LED on a washing machine. Washing machine is only used once a week. The concern is whether the board is clogging up the network with readings every 60 seconds. It might not matter…
Well, an easy solution to reduce network traffic (although I doubt you’d notice these tiny packets) is to simply wire your photoresistor into a digital input, instead of the analog input. Then switch your ST_Anything device type in the sketch from PS_Illuminance to an IS_Contact device. This will result in a digital signal being sent to ST only when the state changes, versus an analog signal every 60 seconds. You’ll have to make sure the voltage from the photoresistor changes enough to trigger both a low and high digital state. You’ll also want to disable the INTERNAL_PULLUP feature on the IS_Contact device since the photoresistor is not a simple on/off switch.
Note: ST_Anything will update the status of all devices attached to your controller every 5 minutes, regardless if anything has changed or not. This is to make sure all devices are kept up to date regardless of how infrequently they are used (imagine a door that is only opened once a month, for example…) The frequency of these updates is defined in “constants.h” in the ST_Anything library folder.
I did the same, bought the little programmer, it’s not what it seems. It needs to be jumpered and so you’ll still need a breadboard. I still didn’t get it working though. Let us know if you get it working and how.