Open andrisole92 opened 6 years ago
Good start - as this issue is related to #10 I suggest you keep an eye of that issue and make sure as those improvements are developed your code uses them (helps us reduce merge conflicts when it comes to pull requests). Small things - can you assign yourself to this issue and add the labels enhancement (as it's not a bug) and esp32 - helps us keep track of stuff. Ta!
Hi @layerzerolabs, okay. Have installed and tested Ultrasonic sensor. Now I see, what the problem is. It seems not to have many errors when the distance is less than 35 cm. And after 35cm the measurements can be wrong.
@layerzerolabs @hamishcunningham What's the typical deployment environment? Would the ultrasonic sensor ever be put in a scenario where it would be trying to make readings of more than 35cm?
We started out having the sensor only 5cm from high water level and measuring upto 30 or 35cm but realised the sensor was getting splashed and corroding quickly - now we mount it 20-30cm above high water mark so we need to read upto 60 or 70cm.
So we do need the results to be conditioned...
I seem to remember (and in the context of #10 ) that we had trouble getting the timing right for the fire-wait-read cycle on these sensors, and also that they tended to interfere with each other in some way, and that I coded some hacks to get around this...
Do you remember where they are? If I can look at them, I can probably keep them in mind when coding solution or simply reuse them.
I've found that previously we used a 35ms delay just after reading each level sensor to ensure that they didn't interfere with each other - I suspect this might not be an issue with only one sensor but you could try it and report back?
As this issue is closely related to #10 I suggest that this issue focuses on passing data to IFTTT and using that to trigger notifications, collect other sensor data and possibly log to adafruit IO - leaving #10 to focus on producing a clean value from the ultrasonics?
Hi @layerzerolabs , I have just tested IFTT and Adafruit. It seems like adafruit can send email notifications without IFTT? And is it right thing to create a new feed for each new sensor/IoT devicei?
Hello - yes but following the survey in lecture 4 it seems that most people wanted notifications using a dedicated app. IFTTT offers this but Adafruit maybe only email or a couple of other options... So unless you can find another way, IFTTT seems to have a role alongside Adafruit IO, one for notifications and the other for logging & dashboard. In terms of how to organise things, I think one feed per sensor makes most sense to me.
Okay. I see 2 ways of doing it:
I found this: https://learn.adafruit.com/using-ifttt-with-adafruit-io/ifttt-to-adafruit-io-setup# which implies you can set up an IFTTT 'recipe' to monitor an adafruit feed - you can then use that to trigger a notification on the IFTTT app which can be parametised.' Please could you review and see if this might be a route you could use?
@layerzerolabs , yeah, I have seen that. The problem is that one applet (service) is created manually for only one feed. If I had 1000 sensors, I would have to create 1000 applets manually, which is.... Not smart?
OK, yes now I understand that was your second option. I suppose when we need to scale we will need to find a provider with an API or host our own... In the meantime we need a solution for a single waterelf that can pass parameters to notifications... other IOT platforms are available like dweet.io. Your call if you want to do more research and discover a better way of achieving the goals of data logging and parametised notifications or accept the limitations of adafruit/IFTTT.
Actually, probably, I will be able to set up a WebHook on IFTTT, with URL, and then trigger this URL using HTTP GET method with parameters such as deviceID. URL will be triggered from io.adafruit.com using a trigger, that can be created programmatically using APIs.
In this case, one WebHook can work for the number of devices.
One thing to decide on, is what to use as an unique feed id. Can I use a MAC address?
Yes, for non sensitive applications like this initially I think good choice. Perhaps combine name and MAC address together so humans can recognise it more easily? And thinking about human readability - can you edit this issue so it better reflects the scope and assign yourself to it please? ta!
Okay, done. Then it will something like USWE-MAC. (UltraSonic WaterElf)
Hi @layerzerolabs, I am just wondering, is it necessary so that IFTTT is triggered by Adafruit.io? Or directly from the source?
By the way, triggers stopped working for some reasons on my Adafriut.io. I can't create any, and some 10, that I have created before just disappeared.
I am also getting a bad char[] concatenation using strcat, like this: "USWE-A89E0CC40A2⸮". With the question mark at the end.
@andrisole92 if you are using strcat are you making sure you a) have enough space in the destination buffer (I would recommend using strncat
instead of strcat
because of this), and b) the argument strings/buffers are correctly null terminated?
Thanks, @Eroc33 , my first char[] was too small. So, it works now!
I suppose we could trigger IFTTT directly - but that would mean sending two messages from the ESP32 - there is always the chance one could get lost, then the two systems would be out of sync... So my vote is for triggering via adafruit. But if you can make a case for the other way round then do, once the code is outlined we can review and collaborate on it, then you can implement collective best way forward?
Also really good to see @Eroc33 helping others - impressive grasp of C - nice one! Probably deserves a cut of my wages...
Hi @layerzerolabs ,
Actually, there is a benefit triggering IFTTT directly - you will know the exact value of the feed, instead of receiving a message, that value is higher than the threshold.
@layerzerolabs , I think I am mostly done.
I have created 6 methods:
bool createAdafruitFeedForUltraSonicSensor(String = "undefined");
- Creates new Feed on Adafruit.io. The problem is that methods AdafruitIO_Feed->exists()
and AdafruitIO_Feed->create()
does not work for some reason and the whole thing halts if using them. So, there were 2 options: use API directly, which would take a lot of time again. Or simply save any value. I have chosen to save 0, so that feed is being created indeed. It is might be better to use APIs, but I feel I need to leave some time for the dissertation report, which is due Monday. The first parameter is the feed name. If the name is not given, the method will return false. The method should return false if it was not possible to save the first value as well.bool triggerIFTTWebHook(String = "");
- simply triggers URL on IFTTT. The first parameter is URL params (e.g. stock=3&username=andrisole
)bool createAdafruitIOTrigger(String, String = "gt", int = UltraSonicTriggerValue);
- Creates trigger for the Adafruit IO feed. First parameter Feed ID, the second parameter is the operator (e.g gt for greater or sm for smaller). Can't find a proper documentation.String genrateIFTTTWebHookURL(String, String);
- generates IFTTT WebHook URL, first parameter - event name, the second is IFTTT Key.String generateUltraSonicFeedName();
- Generates String in format USWE-MAC_ADDRESS
String getAdafruitIOFeedId(String = "");
- Returns the feed id. The first parameter is a feed name.I would like to say, that I feel like triggering IFTTT URL directly might be a bit better. I can check response code to see if my response got through.
I have also done some code work on IFTTT for the WebHook, so the email looks like:
Hmm, I see that you are managing the whole process from the device using the API's - bravo - but perhaps a mixed approach of clicking in the web page to create feeds, triggers etc and then using them with the device would be simpler? Also can you give a really simple overview of what's going on - maybe walk through what happens during startup and then each loop?
Hi @layerzerolabs, Yeah, sure.
The only thing, that needs to be created manually and configured is and IFTTT WebHook. It is a simple URL, that I need to trigger in order to receive an e-mail(SMS and other services can be added as well).
IFTTT WebHook typically takes 3 parameters, which should be named value1, value2, and value3
. This is very useful because I can send device ID and the value, so in case of 1000s of devices, I am able to identify which one has gone wrong.
Now about feeds. I am not sure if manually creating feeds is productive. Adafruit has a good library and APIs for feeds, in case we need 1000s of them.
Well, it is a set of methods, that is not dependent on anything and I am trying to make them as transparent and reusable as possible.
I probably need to change createAdafruitFeedForUltraSonicSensor
to createAdafruitFeed
.
That approach to methods sounds very clean, so long as you can bring it all together then great, bear in mind the opposite concern of solving tomorrows problems today, premature optimisation/generalisation etc.Sounds good - looking forward to seeing how you orchestrate & documentation!
Hi @layerzerolabs ,
Sorry, my laptop died in the demo. I will update my pull request tonight, and some more points to the documentation.
I will also make a small demo in MyThing/Ex16.ino
if that is fine?
I would go ahead with adding to documentation and code but don't worry about demo - we saw a good amount today.
Kind regards
Gareth
On 5 Dec 2017 11:52, "andrisole92" notifications@github.com wrote:
Hi @layerzerolabs https://github.com/layerzerolabs ,
Sorry, my laptop died in the demo. I will update my pull request tonight, and some more points to the documentation.
I will also make a small demo in MyThing/Ex16.ino if that is fine?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hamishcunningham/fishy-wifi/issues/13#issuecomment-349282045, or mute the thread https://github.com/notifications/unsubscribe-auth/AFFUFz99kTw9BRdydL16uu3L5VA7RKUHks5s9S5jgaJpZM4QfR16 .
Collect and analyze the data from the Ultrasonic Sensor: