Ah, yes… That makes perfect sense. I didn’t realize that the IS_Contact had dependencies on the Interrupt sensor. In review, it’s pretty obvious. Don’t know how I missed your code comment: //inherits everything necessary from parent InterruptSensor Class.
To your point, I’ll create a new class that inherits read commands from Interrrupt code. I appreciate the patience in clarifying the coding logic. Your work is pretty amazing! Thanks again.
Dan, thanks so much! I used your sketch and wired everything like you outlined and it works like a charm! Is there any way to donate to you and your son?
I have a few questions though…and feel free to tell me to look through the thread if any of them is answered there. It’s just a little bothersome to read through almost 1000 posts.
The temperature sensors work but I was wondering if the polling/logging interval can be shortened. I am logging the values into an InfluxDB/Grafana setup and could therefore handle quite a few updates if the temperatures change. In my solar setup it is possible to see temperature spikes of more than 100F which then falls again quickly after a few seconds. I would like to capture this better for my analytics.
So my question is: what is the general architecture of the solution and what is the bottleneck? The ESP8266, the ST hub, the ST cloud?
Would be nice to send all detected value changes plus a periodic value every x seconds even if there is no change.
Related to this: I have seen some delays from time to time (so I suppose the data goes through the ST cloud). It didn’t seem like the values send from the ESP are time stamped but the time stamp is added upon processing of the (delayed) data. Is this correct? Would it be possible to have the ESP create the time stamp somehow so that the event is later logged at the correct time?
And something unrelated: I saw that you have example sketches for alarm systems. I stumbled over the Konnected project a couple weeks back (and am still waiting for the hardware from China I order for this) and am wondering if there are any pros/cons regarding the two different solutions.
Sorry for this badly structured post…but it’s pretty late here. Any help is appreciated, even though I don’t understand how you can keep up with all the questions in this thread.
I had my temp sensors set for every 5 seconds when I was doing testing and it seemed to work well. You can open up Serial Monitor to see how often the chip is actually polling, which should be time stamped (?), and trying to send data and compare that to the ST side to see the delays. For my purpose, outside air temp and humidity along with garage air temp and humidity, I have it set for 60 seconds and am actually looking at increasing that a little more, probably 2 or 3 minutes for outside and 5 for garage should be more then enough. But it depends on the situation.
As for the Konnected comment I can chime in a little as I have both a ESP32 running ST_Anything and 2 Konnected panels. As a huge generalization Konnected is easier to get setup (no static IP required) and use “out of the box” (just plug in and go) but isn’t nearly as customizable (no voltage readings, temp sensors, etc). If you are comfortable with ST_Anything it will do everything Konnected does and then some. If you are not comfortable with programming and would rather have something thats more packaged then its a good option.
Hello Dan,
I’ve had a moment to process your suggestions and I just wanted to clarify a few points. You mentioned that:
in the normal IS_Contact device, a pin # is passed in when the device is created. Specifically “That pin # is used internally by a digitalRead() Arduino standard call to retrieve a value.”
However, the main .ino sketch appears to manually assigns pins for certain sensors, (i.e. #define PIN_CONTACT_2 27 //SmartThings Capability “Contact Sensor”).
I then assume that a device created with the following code is then mapped to the corresponding pin location.
static st::IS_Contact sensor14(F(“contact4”), PIN_CONTACT_4, LOW, true, 500);
Trying to duplicate this mapping nomenclature with corresponding sensors on a PCF8574 is problematic. The PCF8574.h labels the individual pin P0-P7. Since they all communicate via SDA pin (pin 44 MEGA), each unique P0-7 location is reported as expander(0), expander(1), expander(2). The initial working bench test did not behave as you suggested with binary value assignments of HIGH/LOW. In addition, when multiple I2C bus are added, the pin location becomes expander1(0…7), expander2(0…7), and so on. When I substitute expander.digitalRead(0) with expander(0) it returns an error “no match for call to ‘(PCF8574) (int)’”
I know I’m probably talking in circles and not seeing a simple and obvious correction (probably one you already suggested). I’m believe the issue is properly mapping the location of each of the sensors attached to the I2C hub, since I can’t use the typical declarations of PIN_CONTACT = X. X = value 1-50~
Whatever the case, I realize this is way beyond my understanding and expertise. If you happen to find a solution, that would be great. Otherwise, I think I’m going to abandon this topic and move on. Thanks again for your feedback and all the time spent creating the ST_Anything code.
Based on your screen shots I see colons in the MAC address. Try removing those. If that doesn’t do it delete the parent device, add it back in with a slightly different name, make sure you set the location and hub (put in random stuff for network id…it will be overwritten), and try it again.
Thanks, done that and it seems to be working 
,
But it does seem to fly in the face of what the serial output says to do…
Enter the following three lines of data into ST App on your phone!
localIP = 10.0.1.33
serverPort = 8090
MAC Address = A0:20:XX:XX:EC:8A
Big Thanks
I believe you would need to pass into your new class a reference to the “expander” object as well as a “pin #” for the expander. Then, your new class would have the two items it needs to read the value of the physical device, and then properly update SmartThings.
Gary,
Yes, that MAC address does seem to confuse many people. That is why I clearly state in the ReadMe that you must remove the delimiters (i.e. the “:” colons) and use all uppercase. I even provide an example of what the result should look like.
Here is a quote from the ReadMe
When entering the MAC address into the Device Preferences in your phone’s SmartThings App, please be sure to enter it without delimiters, and in uppercase. It should be in the form ‘06AB02CD03EF’ without the quotes.
I am very glad to hear you have it up and running!
Dan
@BornInThe50s - The main set of instructions say to only use letters and numbers but I do get it, you see it in serial monitor so naturally you just want to copy and paste that into the device.
@ogiewon - I’m not near a computer right now to look at the code but maybe you strip the colons out before printing that to serial monitor?
Yes, you can very easily change the polling interval by simply modifying the sketch’s setup() routine. In the sketch I created for you, the polling interval was set to every 30 seconds.
static st::PS_DS18B20_Temperature sensor1(F(“temperature”), 30, 0, PIN_TEMPERATURE_1, false, 10, 2);
Each time this interval expires, the sensors are read and the data is transferred to SmartThings, regardless of whether or not the values have changed. This ensures the ST cloud is always kept up to date.
All of the parameters for your temperature sensors are configured when you create the device. Simply adjust these parameters as you see fit, but please do not overwhelm the ST Cloud infrastructure with useless updates. Temperatures typically do not change instantly, so sending data updates every second is usually just sending noise and contributing to the workload on the Cloud Servers.
At the top of every class’ .h and .cpp file you will find documentation in the following form:
// Create an instance of this class in your sketch's global variable section
// For Example: st::PS_DS18B20_Temperature sensor1("temperature1", 120, 0, PIN_TEMPERATURE, false);
//
// st::PS_DS18B20_Temperature() constructor requires the following arguments
// - String &name - REQUIRED - the name of the object - must match the Groovy ST_Anything DeviceType tile name
// - long interval - REQUIRED - the polling interval in seconds
// - long offset - REQUIRED - the polling interval offset in seconds - used to prevent all polling sensors from executing at the same time
// - byte pin - REQUIRED - the Arduino Pin to be used for the One-Wire DS18B20 sensor conenction
// - bool In_C - OPTIONAL - true = Report Celsius, false = Report Farenheit (Farentheit is the default)
// - byte resolution - OPTIONAL - DS18B20 sensor resolution in bits. 9, 10, 11, or 12. Defaults to 10 for decent accuracy and performance
// - byte num_sensors - OPTIONAL - number of OneWire DS18B20 sensors attached to OneWire bus - Defaults to 1
Correct, no time stamps are sent from the microcontroller. In fact, the microcontroller doesn’t even know what the current date and time are!
As for delays, I believe that can be a result of the ST cloud back-end taking its time to process the incoming data. Also, if the data from one update to the next does not change, the SmartThings cloud may decide to ignore the update. This could also lead to the perception of a “delay” in the data stream.
Konnected is a nice package, being built for users who want more of a turnkey solution and who are willing to pay for it. One major limitation with Konnected is that it currently only supports the ESP8266 board with very limited I/O. In order to get more I/O points, you need to add more ESP8266 boards. Also, as Allen mentioned, Konnected currently is mostly about Alarm Panel replacement. I expect Konnected to keep growing and expanding over time. Nick’s choice of the ESP8266 was a very good one, IMHO. It provides great WiFi and a low price. By focusing on one board, he is also able to exploit that board’s feature set (like OTA updates, for example.) HOwever, he chose to not use the Arduino IDE for programming the ESP8266, which makes it more difficult for home hobbyists to modify and expand the capabilities.
ST_Anything runs on basically any board that is compatible with the Arduino IDE. This allows you to choose one as small as an ESP01 with just 2 GPIO pins, up to an Arduino MEGA 2560 with 70 GPIO pins! ST_Anything also supports hard-wired and WiFi connectivity, as well as the original SmartThings ThingShield. It is designed as a home hobbyist open-source platform, and I encourage user contributions to GitHub repo to expand its capabilities. I have provided some frequently requested examples, like the Alarm Panel replacement one to help users get started. Once you get the hang of it, it is really very easy to customize one of the example sketches to meet your particular needs.
Hope this helps!
Dan,
thanks a lot for you answers. You didn’t answer the most important questions though: is there a way I can pay for a couple beers for you and your son? The amount of time you have invested into this solution must be immense.
I certainly don’t want to flood the ST_Cloud with unnecessary updates. I will see if I can tinker with the code so that the temp is polled every 3 seconds or so but only sent if the temp_delta is > 2F…or something like that. In addition stick with a 60 seconds update interval. That should be a decent middle ground.
One question regarding updates: What are the implications of updating/flashing the ESP8266 regarding the existing ST devices? Will I have to re-create everything again?
Thanks in advance
If you ADD devices the ST side should see the missing child device and auto add it. If you DELETE something you may have some issues, the device may remain and just not update. You can delete the now missing child but as many notes in this thread say you might have issues and have to delete and recreate the parent. If you want to re-order stuff you’ll have to delete and recreate the parent otherwise things all messed up.
Otherwise you can change code within the libraries, change polling times, etc, without having to do anything on the ST side.
I have modified all of the “SmartThings…” libraries to remove the colons from the Arduino Serial Monitor window. I have also added RSSI to the WiFiEsp library for using the ESP01 as a serial WiFi dongle for an Arduino MEGA.
All of these changes are in my GitHub repository if anyone wants them.
Dan
We’re talking about sensors that only cost a few dollars, so a little noise is somewhat to be expected, IMHO. Per the DS18B20 spec sheet, the accuracy is “±0.5°C accuracy from -10°C to +85°C”, so seeing ~.45°F of variability seems pretty reasonable. At 10bit, the DS18B20 should provide ~0.3°F resolution increments (-67°F to +257°F = span of 324° / 1024counts = 0.31°/count). So, with rounding, seeing 0.45 is definitely in the ballpark.
Are you seeing the variability in the Arduino Serial Debug Monitor Window? In the ST App on your phone? Or both? Just curious if we can pin down the source of the variability.
Hey, you answered before I could delete my post. Figured out, that a value of 58.05 was indeed possible because the resolution is referring to Celsius and I also had a 4 degree offset. So it actually alternated between 54.5F and 54.05F which equates to 14.5C and 14.25C respectively. So I guess the temperature was just right between those two values and the sensor reported them correctly. Everything is good…sorry for wasting your time.
Mark and Steve,
I have updated my Github Repo with a new version of the “SmartThingsESP8266WiFi” library that has built-in Arduino OTA support. It is enabled by default and there is no password for the updates to try and keep things as simple as possible.
If you have code in your sketches to enable Arduino OTA updates, you will probably need to remove it to avoid any conflicts.
Give it a try and let me know what you think!
Dan
Thanks Dan, I’m away at the moment but I’ll try it out as soon as I can.
I did get something working, and updated 4 of mine ota. Unfortunately, although the network ports stayed available in the Arduino IDE for a couple of days, they disappeared after a computer reboot, so there’s something not quite right with my setup…
Thanks again.
Mark.
Once again, big thanks to you and the other people who helped me get it working. The reason I copied and pasted from the serial output and caused my little headache is somewhat daft. I was working on my PC and read in another post that another user had problems getting the app to save the settings and had used the IDE to enter the config. Hence, the copy and paste from the serial output to the IDE device. Plus, the only other time I’ve entered a MAC without the colons is in DHCP reservations on Windows servers.
Anyway, forward to start using it
If anyone can point me in the direction of a numpties guide or help in getting one of these - I2C IIC Serial 128X64 OLED LCD LED Display SSD1306 Module Arduino, to display the Arduino pin status for the devices I plan to use? I’d be grateful, I’m already looking through sketches, forums etc to get some ideas and realise it’s really beyond the scope of this thread.