ESP8266 Community Forum

- Mon Sep 15, 2014 2:42 pm #599 Ah, I was under the impression it was LwIP, based on the SDK library names. Contiki uses uIP, right?

IPv6 would be good. I didn't realize CoAP supported multicast messages, so I guess you could use that for discovery as well. You'd still need a home automation protocol to run on top of CoAP, but that might be lighter weight than full HTTP.

- Mon Sep 15, 2014 3:55 pm #601

Ah, I was under the impression it was LwIP, based on the SDK library names. Contiki uses uIP, right?

IPv6 would be good. I didn't realize CoAP supported multicast messages, so I guess you could use that for discovery as well. You'd still need a home automation protocol to run on top of CoAP, but that might be lighter weight than full HTTP.

I saw somewhere that is was uIP, forget where it was. Their JSON code is from Contiki.

UPNP over HTTP with SSL would be best. Contiki has a small web server in it already. I would ignore COAP and only use it on batter power devices. In my case I am totally ignoring COAP and using BLE.

Advantage to getting Conitiki working is that it is in fairly widespread use (for an IOT OS) and it has been around quite a while so it is debugged. It is also fully open source. To port it you need to write a timer driver and a packet driver. Two things that should be in the ROM. Then you can add mini device drivers for things like flash.

But porting Contiki is counter productive if xtos is in ROM. So have we determined if it really is ROM is just RAM pretending to be ROM?

Where I get my modules

- Wed Sep 17, 2014 11:42 am #704 I went back and read our notes on UPNP. We concluded that today it is a bad idea (it was a good idea ten years ago). The better system is JSON.

That brings back the problem of how do you discover the things? We solved that by having the devices post their addresses to a cloud server. The posts contains the ESP8266 address on the LAN not a public IP which they don't have. A cloud server builds a page for each house. When you browse to the cloud page is gets constructed with the known LAN IP addresses of the devices and some Javascript that builds a UI to control them. Pages like this only work if you browse to them while on your LAN. They won't work from outside your house.

Another solution is to use the same scheme inside a house. But this requires a known server that you can install code on to. For example each of the ESP8266 knows its default router. If the default router is running OpenWRT you can install an app to receive posts from the ESP8266s and construct a web page. This could also be done using broadcasts and an app that is always running on the router.

Where I get my modules

- Fri Sep 19, 2014 2:06 pm #764 Still, there are ways to do it without having any hard-coded server. I prefer not to use Cloud servers if possible, for various reasons but primarily because they're unavailable when the internet's out on either end. What do you do when you can't reach the Cloud and your IoT thermostat's going haywire?

I also hope you hash the house IP, because otherwise the Cloud server has both the public address of the home network as well as the internal address of the IoT device. Spoof or hack the router and you've compromised the IoT device.

But the simplest solution is the one you suggested earlier: CoAP. Have the IoT device running a CoAP server and listening to multicast, and have any client device broadcast a CoAP query for /.well-known/core, which every server must implement. No XML, Cloud or hard-coded addresses needed.