Вставка
- Опубліковано 7 вер 2024
- In this video,
- We will discuss the relevance of the COAP protocol and where it is used
- Create an idea about the concept of RESTful APIs I already used in video #27
- Understand the basic differences between COAP and MQTT
- Use COAP on ESP8266
- We will learn a little on how to “spy” networks using Wireshark
- And of course, we will be prepared to hack the IKEA Tradfri gateway in the next video
Links:
ESP8266 CoAP Library: github.com/aut...
ETH Zurich CoAP Test Server: coap://129.132.15.80:5683/
Copper Firefox add-on: addons.mozilla...
Supporting Material and Blog Page: www.sensorsiot.org
Github: www.github.com...
If you want to support the channel and buy from Banggood use this link to start your shopping: bit.ly/2jAQEf4 (no additional charges for you)
/ sensorsiot
/ spiessa
Andreas, you're amazing!
In 6 minutes (I watch UA-cam at 2X speed), you taught me what COAP is and how it's different from MQTT. Thanks for sharing your knowledge!
So, two Swiss equal one American (at least in English language ;-)
2x is so fast. I like 1.25x for slower talking videos
I can't agree more Andreas. I love you and your videos so much. Thank you for making them!
+ReanimationXP :-)
One of the most exciting, didactic and inspirational 13 minutes I have ever had! Looking forward full of anxiety to #145!!!
+jesuschal Thanks!
Fantastic. You never ceases to amaze me. This is really interesting and useful but I have no idea how you manage to do so much. Looking forward to the next episode. Thank you for sharing so much with us.
Best wishes
Arthur
If I want to be successful on UA-cam, this is how it has to be ;-)
Just wanted to say that as always I enjoyed your video and to point out that your approach in presenting information is superb. Flow of the video is always well structured and easy to follow. I always get excited when I receive an email that says you have posted a new video. Keep up the good work!!!
Thank you for your nice words. The next mail should come tomorrow, 6AM Basel time...
Andreas Spiess Looking forward to it! Thanks
Andreas, you're an amazing teacher! You have a gift sir, taking difficult topics and explaining them in such a simple way. I wish you were my Engineering Professor when I learned.
Thanks your for your nice words!
I had not heard of CoAP. Thanks for the introduction. I am looking forward to learning more about it.
+Perspectologist You are welcome!
The balance of what level to explain stuff is emminent! Not something I find often. Good job :)
Thank you!
Thanks for the great presentation! CoAP's service structure feels easier to grasp and when it is presented under the coap:// protocol within a browser, it feels much more user friendly. Hoping that MQTT will have such ability in the future.
You are welcome!
you, sir, deserve at least 1M subscribers. Thank you for very well explained videos.
You are welcome!
Andreas, thank you very much! I needed some starting point for CoAP, and I knew that you will have a video about it. Thank you!
Glad it was helpful!
Great to see you using the Wireshark filters Andreas. We ready need a Ikea in my home town as the closes one is 170 km away.
They tell us here, that 170 km in your country is like 17 km here in Switzerland. So, your IKEA is only about 50% further away than mine...
And here, they started a Web Shop. Maybe this helps in your situation even more.
Andreas Spiess Maybe it does, how you make me laught. Now off for some milk it's only 7 km away. Or in your terms 70 km's one way that is 140 kms round trip.
Great work Andreas 👍
Definitely useful and interesting. Having mastered MQTT with the aid of your work, I'm ready for COAP😀
My interest spiked when you made a wonderful comparison with MQTT, that really helped me to make sense and importantly why I would want to use it.
As always looking forward to everything you produce.
Your time and effort is gratefully received. 🙏
I think, at your Sunday breakfast you will see a usage of this new technology...
Andreas Spiess ohh 😲 I'm really happy about that🎯
Great video - I really appreciate the way you outline the steps and walk thru them explaining as you go. Very easy for me to learn and understand, and very interesting too!
Thank you for your feedback. It helps me staying on the track...
I've been looking for a consice explanation of coap!! Thanks for making this video. I remember when I was messing around with Mqtt back in 2016 and couldn't find a simple explanation of coap. Thanks for making a video I can forward to others at work!!
Thank you for your nice words. COAP was also new to me. This was the reason for this video
Sir, I am really impressed with your teaching approach. You taught me how simply many things can be explained. Hope you will guide us in future as well.
Thank you for your nice words!
Great video Andreas. Useful summary and comparison of the two protocols. Liked the wireshark analysis as well. Looking forward for the follow up video!
Good to read that you like my content!
Simple and concise with real examples! great turorial!!
Thank you!
Thanks for sharing. nice to get new information for the IoT communication😀👍
You are welcome!
Great video, Andreas! For the average home gamer using something like the ESP8266 MQTT will probably always be the easier solution, but there are huge benefits for using CoAP on a more industrial scale:
Transparent CoAPHTTP Proxies exist, allowing you to reuse existing infrastructure. Reliability is part of the protocol, but how much you want to pursue it is left to the implementations. There are extensions to CoAP like CoAP-Observe that enable you to deal with sleepy nodes very well. You should take a look if the IKEA system supports it!
A small implementation of CoAP (including DTLS!) can run on systems with less than 10 KiB RAM and 100 KiB ROM. It also works great with low power lossy networks like 6LoWPAN. This means huge cost savings when dealing in big volumes.
CoAP is also more flexible. In a student project, we implemented a decentralized home automation system with CoAP that did not need any external cloud or central server to function. Apart from the much better privacy, such a system also allows for more fine-grained authentication (what devices on your network should your IoT Fridge be allowed to see?).
It is very promising in M2M applications as well, where you can use the RESTful design and the multicast discovery mechanics to build self-configuring interoperable systems. If standardized correctly, this could mean a generic "IoT switch" could turn on and off any "IoT light bulb" regardless of vendor or further capabilities.
The combination of these two architectures could allow an Internet of Things were you yourself are actually in control of your data, devices and interoperability instead of the people that build them.
This is of course only wishful thinking ;)
Thanks for your comment. I think, we will see the advantage of the discovery mechanism if we deal with the IKEA bulbs. As I said in the video, fortunately, both concepts are different and have advantages and disadvantages. And this is good. We have the choice. I do not like if two different standards are too similar, because this only creates confusion, uncertainty, and cost.
Hi Andreas, thanks for this very informative video. CoAP was new for me, so this was very welcome information. Danke!
I think, CoAP was new to many of us. This was the reason I thought, I create this video
Andreas, you've really got me excited about home automation! I'm renting an apartment, so I can't do some things. I have managed to get about half my lights working with Alexa (mostly on ESP8266+relay). I'm working on getting MQTT going, and probably a Home Assistant front end, so that my control doesn't disappear if my internet connection goes down.
I think, your situation is the biggest obstacle for home automation: houses without the needed infrastructure like wiring. So, Home Automation systems are either extremely expensive, or not nice to look at...
The Sonoff device from Itead is another choice - consumer ready using ESP8266. I ordered several a few days ago. Hopefully I can watch Andreas videos about them before they arrive. :-) #99, 111, 113, 122, ...
Eric Jacobsen -
I have a couple of Sonoffs I'm tinkering with myself. Thanks for the episode listings.
My ESP8266 setup is controlling a 2 relay module, that replaced a couple of switches for built-in lights in my apartment (I'll put the switches back when I leave). Right now, they are just running Fauxmo to work with Alexa, but I want to build an MQTT setup so I can still control my lights if my internet connection isn't working.
I also like Andreas' motion sensor idea using Node-Red. I have some places I'd like the lights to come on temporarily if I go into the room, but stay on if I tell them to.
Thank you! All the tools you introduced are just pure gold
I just wish I was able to find this video way sooner!
You are welcome!
Can't wait till the follow up of this as I've just bought some Ikea lights and have started looking at home automation :P
You have to wait till Sunday, 6AM
Andreas Spiess which timezone? :)
Andreas you are my hero. Thanks for another great video. looking forward to Sunday morning for the next one. Cheers.
The next one is simpler (I hope, at least)...
Every episode opened my eyes more. Thanks!
You are welcome!
Thanks for sharing, Andreas your tutorials are always hitting the nail on the head.
Thanks!
Amazing how you keep on finding interesting topics to make these great videos on.
I did not find it. If found me...
I'm already looking forward to watch the part two.
Already in production...
Andreas I'm really sorry I started this lengthy discussion with my linguistic pun on the previous trådfri video.
It can be an interesting discussion but it's a rabbit hole for a technical channel like yours.
No problem at all for me. It was very interesting to see, how much we are still "patriots" compared to "Europeans" ;-)
Andreas, so happy to have find your channel. Good stuff!
Welcome aboard!
Hi Andreas, here a big fan from Holland. I looked at every video. it's giving me ideas and I learned a lot.
I want to thank you for that.
groeten, ( :) )
Marcel
Thank you for your nice feedback!
Thank you for a lot of great videos. Just a quick note. There is also a PATCH method in restful API.
Thanks for the tip. I did not know that.
very cool and understandable overwiew
Thank you!
Simple yet great video, thanks a lot.
You are welcome!
Can't wait for the next episode! :)
:-)
Very good explanation Schweiz, Congratz! Danke!
+Lucas Camargo Thanks!
Seems like the discovery would be a major upside for coap as well. That mqtt doesn't have this really makes things more cumbersome to set up.
As soon as an MQTT node is connected to a broker it easily can be detected according its messages (Home Assistant does that, for example).
@@AndreasSpiess oh ok, then maybe it is only my shelly devices that dont have mqtt Discovery implemented, and therefor need an external script
@@carlborgen I just started with Home Assistant, and it discovered my Shellies...
@@AndreasSpiess So are you running your shellies via mqtt then or the CoIoT protocol? Because when I ran them over mqtt I had to use the discovery script, which resulted in other issues. So I have now renounced my mqtt purist ideas and run them over the CoIoT integration as well
@@carlborgen I played with both. Currently, I use the Shelly integration of HA
Hi Andreas,
many thanks for this and all the other really good videos and explanations. Short question: you refer to video #27 for RESTful APIs, but that contains 3D-Printing. Did you maybe mean video#29 instead which talks about "Calling RESTful JSON Services"???
Yes, you are right. Sorry for my mistake
Very good course, as always...
Thanks!
THANKS ANDREAS,
You are welcome!
Always a 👍 for you sir, the quality & frequency of your output is so impressive. How does wireshark perform on the RPi?
It does its job. In general, the speed is not as high as on my desktop. But this is ok. I also do not have a lot of experience, I only use it occasionally if I want to solve a particular problem.
Andreas, you're too good !
:-)
Thanks for the video =)
My pleasure!
Good work, as always.
Thanks!
Hello Andeas, thank you very much for all your easy explained videos. If you hacked the IKEA Gateway, do you think it would be possible to use the Tradfri Remotes and Motionsensors as seperates device. I use FHEM to automate my home, but unfortunatly all the plugins I cloud find weren't able to use the triggers as seperate device and they get uselesse when the bulbs are managed by fhem. regards
The remotes still work with my gateway (in parallel to the signal from the Raspberry. But, of course, you cannot connect tehm to your Raspi because they use Zigbee. But you can read the status of your bulbs with the Raspi.
The reason Trådfri doesn't translate in swedish is because it's not a proper swedish word but a play on words 🙂
From the lengthy discussions, I also learned, that the same applies for Danish...
Same for Norwegian. It's a perfectly valid compound word (if a bit clumsy), but not in the dictionaries. And while Google translate translates the "Danish" Trådfri to "wire-free", if you try with Norwegian you get "suture-less". Isn't machine translation fun? ;-)
True. The correct danish word is "trådløs" though. "Tråd" meaning wire, "løs" meaning without
Very interesting. Thanks!
You are welcome!
I'm too invested in MQTT to change. I don't even see features that are unique and wanted badly.
Who here knows the limit of data transfer (Bandwidth in MB/S or KB/S) using a RPI running Mosquitto? I have not been able to find that info!
I want to connect an ESP8266 to my lab test equipment but not sure at what speed it can stream data back to me through MQTT.
+UFOhunter I think, it is not about change. It is more to understand the differences. And if I want to use MQTT for the IKEA bulbs, I have to deal with COAP.
So with MQTT there is the broker, how is it done in COAP. I only got that there is a client and Server. I understood the COAP's client/server model ( UDP ), but does that mean this is a point to point ?
Can a client also be a server as is in MQTT?
Raad Yacu with CoAP you can decide whether to keep server or client or both depending on the architecture.
As I presented in the video, usually, you have no broker with CoAP.
well... here we are 2 years later...
is there any good CoAP library for the Arduino framework?
The "CoAP-simple-library" is too simple :( There is also "ESP CoAP" but so far I didn't manage to get it working :(
I did not use it since then. So I hav no additional info.
Dear Mr Andreas, thanks for the valuable video. Currently I am playing with ESP32, I would like to see how a client (with a, say, temperature sensor) and another client (with, say, a humidity sensor) could send their information to a COAP server that would, according with some pre established parameters, switch on a pump (or provide this info so a third client could do so). Thanks again.
Maybe you google for an example. I showed what I know.
@@AndreasSpiess Hi, thanks. I tried Google but could not find any scenario with some ideas of how a measurement in one client could propagate and influence another client. But will keep looking. Thanks for your great videos.
thanks a lot for your video it helps me a lot
You are welcome!
this extension is not available anymore and I tried many Github repository to solve this problem but is still not solved . how I can solve this problem
I use now Zigbee2MQTT for the IKEA bulbs (see my video). It works quite well.
Have you tried LWM2M? I'm looking into trying it.
No, never tried.
Also, is CoAP ip dependent? I guess an upside with MQTT is that you don't have to worry about giving everything static ip adresses?
No difference. Both need an IP address (because they reside in a Wi-Fi network) which can be static or not. COAP uses UDP, BTW.
@@AndreasSpiess sure they both need an ip, my point was that the mqtt device doesnt stop working in case the dhcp server suddenly changes the device ip. As I understand coap identifies devices by ip, whereas mqtt only identifies via topics?
@@carlborgen I assume the node knows its server or broker address and initiates communication. If the server address changes the problem is the same. But I do no more remember the details of COAP
@@AndreasSpiess When I added a shelly device to HA over CoIoT (Based on CoAP) I had to add the node via it's ip-address. Which is why I was worried that maybe it would break if my routers dhcp server suddenly decided to assign the node a new dynamic ip. Worth testing
@@carlborgen I do not assign all addresses to DHCP to have space for static addresses.
I'm sorry i'm not so good but i would like to understand how to repeat the signal to control bulbs situated out of range of the gateway, can you suggest me how to solve the problem?
This is an old video and I do no more remember. But I made newer videos using IKEA Zigbee bulbs and witches.
@@AndreasSpiess tnx a lot for the answer!i will search and look for it.
Any attempt to create protocol based on HTTP to solve modern tasks will fail. It is not designed for that especially for IoT. HTTP based protocols will consume to much power (battery), too much traffic. I only listened your video till this statement that it is HTTP based and I quite. I do not have time to learn doomed technologies. Even if it has so many features and simple and convenient to use. I'd better spend time to learn something worth.
So thank you for informing me on the nature of CoAP.
Glad it helped!
Again a very interesting video. Thank you, Andreas. Do you know if it is possible to use the ESP8266 as MQTT broker?
I never saw a 8266 as a broker
What replaces Copper Plugin now after firefox stopped it?
I do not know.
Google translate used to convert "the Grapes of Wrath" into "the Angry Raisins"
:-))
mqtt is like and irc chat..
qos is very important in iot.
plus you can have many servers and broker to broker.. nodes are infinite,
in arduino works great..
My words...
Great ! As usual !
Thanks!
Very informative :-)
Thanks!
Great video!
Thanks!
good video!
Thanks!
You're the man, Andreas! Awesome video :D
Thanks!
Doesn't MQTT use TCP normally, by default?
I do not know if MQTT is bound to a particular lower laywer communication. I just use it ;-)
So even if you are using the gateway you still need the remote? Is there any way to get rid of it?
I do not know one.
@@AndreasSpiess ok thank you for answering
fyi: the new openhabian 2.1 supports Tradfri
+Ed19601 Thanks for the info. From where I stand now, it is not complicated to support it.
Wireless in Danish is "Trådløs" Exactly like in German "Drahtlos". "Trådfri" - "Wire free" is very much a Swedish word, which doesn't exist in Danish. Why Google don't know that?
Maybe I did not ask properly :-(
Copper Firefox add-on: addons.mozilla.org/de/firefox
the link is loose !
Thank you for the link!
Dear Mr Andreas, on the browser view at around 7:45 the browser shows a service exposed by the COAP server named LED. I checked the github.com/automote/ESP-CoAP and the coapserver.ino and did not find this "LED" but something as "LEDSTATE". I am trying to understand how this COAP thing works and trying to make it work with a ESP32. I am trying to understand how the server exposes these services and by clarifying this "LED" question above you will sure help me understand where it comes from. Many tanks and congrats for the nice tutorials.
By the way, I found a Copper agent that works with the current version of Chrome that may be of interest at: github.com/mkovatsc/Copper4Cr and it works great.
Regards
This is an old video and I do no more remember the details. So I cannot help you :-(
very similar to ble protocol
I so far never looked at BLE. But I am sure, I will have to one day...
👍
Can I play the annoying complainer for a moment.
- REST is a pattern/architecture style. Most, what are claimed, REST APIs on the internet don't follow the pattern and are called HTTP APIs/web APIs instead of REST APIs.
- The methods are part of the HTTP RFC (2616). REST didn't invent them and they're not REST methods. REST requires CRUD-like operations that you apply to an identifier and it's only in the context of HTTP that this becomes OPTIONS/GET/HEAD/POST/PUT/DELETE/TRACE/CONNECT. Or in CoAP (7252) it becomes GET/PUT/POST/DELETE.
- The URI is part of the URI RFC (3986) so again REST didn't invent them. REST doesn't care if you use /books/id/1930 or /books?id=1930 but it requires that a resource is identified by it's URI.
REST is a buzzword and wrongly used most of the time. It was simply a pattern made by the same guy designing the HTTP protocol and used to explain HTTP. A few years ago some asshole must have used it on Twitter. Patterns are like fashion, they never go away but simple people forget and greedy people profit from reinventing something that doesn't require effort anymore.
Thanks for your insight. I am glad I am only a simple engineer and not historian nor judge! For me, questions like "does it help to solve the problem?" or "What are the differences between concepts in the light of solving a particular problem?" are more important.
@Rizon1985. You are correct, but beside the point. The video does an admirable work of explaining in very understandable terms (even to the layman, I believe) the basic concepts and differences between the protocols. It focuses on the relevance of the concepts, rather than on establishing first a full historic perspective and academically correct taxonomy. I believe focusing on relevance to be a perfectly correct, effective, and desirable approach for this kind of work and its target audience. I also believe your observations are correct, but they are most relevant and useful within the scope of a computer science course.
I agree it's a beginner type of video but REST has become this buzzword that confuses beginners. I even meet professional people who use the word REST like it's a protocol or a framework. People payed to know it, don't know it is nothing more than an architecture pattern.
It's perfectly normal in education to first learn a concept in an easy form and then expand it. And that's what this video also does and it's good. But I feel it says that GET/POST/PUT/DELETE defines a REST API.
I know it's a minor thing in most eyes and it's not the main subject of the video. That's why I called it the "annoying complainer". If people understand HTTP, MQTT and CoAP are protocols and what some of the differences are, the video has succeeded in the main message.
If we want to be really precise: If you listen closely to my video, you will hear twice "concept of REST" and never REST protocol.
I don't mean you said REST protocol. But for example at 3:12 you talk about RESTful methods while you're talking about HTTP or maybe already CoAP methods It might make someone think there is a thing as a RESTful method but it can't because REST isn't a language or framework or standard.
/LED/ for example would better be /LEDs/ returning the collection and /LED/{id} for a specific LED because the machine at 192.168.0.10 can have multiple LEDs. Or if only asking if a LED is turned on rather than the full details it would be /LEDs/status/{id}. But in your reply you would also communicate your service structure and available methods for the objects.
So you have a CoAP API at 192.168.0.10 but it isn't REST. Which is perfectly fine because making a service REST is terribly complicated and time consuming.
Ich hetts gärn uf schwyzrdüttsch ghört - abr guet lärnt mer da englisch :-))
Tönt ja fast wie Schweizerdeutsch. Mit meinem Akzent ;-)
and 5 years on, where is part2?
Things moved in different directions...
@@AndreasSpiess So would you still recommend CoAP?
@@RandomPsychic I cannot recommend COAP because it is just a protocol. You use it if you need it ;-) It is a well known standard
Andreas
?
MQ Titi *gnihihihih* #iam12yearsold
Er du Dan?
??
He asks if you are "Dan"? I think its an abreviation of Danish or "Dansker"
😂😂😂say in your Ch accent in German "Troodd-ffriiii" will be like in Swedish or in Norwegian "trådfri"
Tradfri is Dutch, the language of Germans. Get your facts straight!
You are right!