I noticed that the you made a config front-end using a web page and claimed that you're not up to date with web development. Indeed, I do find that it's unsatisfying to configure IoT devices over the web, although the web is one of the most compatible solutions. The drawbacks include the fact that if you want to configure it you always have to be on the same LAN and figure out its IP or port-forward, but if you port-forward, it will be not very secure due to the attack surface of the mini web server. Moreover, it's not very elegant for you or others to programmatically control it.
My interest recently has been on the mqtt protocol, it's like microservices for IoT. You will need to connect to a middleman mqtt server and hold that connection. When you want to change something you push the changes to the middleman mqtt server. It can be local or on the internet, but since the mqtt server is maintained and updated, it's much easier to secure the mqtt server. Or you can use someone else's mqtt server as a commodity. The app called "mqtt dashboard" acts as a client and allows you to draw a number of controls to the client if you answer a specific request. I think it's suitable for applications like this. Hackaday has a detailed article about it. I think mqtt is a great example of a great protocol for the purpose of controlling/configuring IoT devices.
> The drawbacks include the fact that if you want to configure it you always have to be on the same LAN and figure out its IP or port-forward, but if you port-forward, it will be not very secure due to the attack surface of the mini web server.
But MQTT suffers from all of these same drawbacks, does it not? (MQTT is a TCP based protocol, and will thus suffer the same issues w/ NAT, and has no security aside from "can be run over TLS" (which I frankly think is okay / the point of layers of abstraction / I would not encourage re-inventing the TLS wheel; my point is only that MQTT and HTTP are in the same boat, AFAICT.))
> Moreover, it's not very elegant for you or others to programmatically control it.
I would think the ecosystem for HTTP vastly outstrips that of MQTT's…
>But MQTT suffers from all of these same drawbacks, does it not?
Your MQTT IoT device is a client, not a server, so you don't need to deal with no NAT.
Even if you're outdated and has security problems, as long as the server doesn't exploit you (and filters out the requests that exploit you), then you're safe. It's really hard achieve that with an outdated HTTP server.
No. With MQTT, the client device makes a connection to some external MQTT server-- AWS, GCP, and Azure all have IoT bridges that speak MQTT.
There's often an equivalent service over HTTP/1.1, where devices occasionally poll a remote endpoint for commands and to update state-- but without the persistent connection, you can't do realtime commands.
I added that link to my reading list. Very interesting idea. I'll be looking more into MQTT.
But I don't see the issue with exposing the HTTP interface to the world? I'm always leaning towards solutions that ship with web interfaces, especially over mobile apps because I can use third party apps to work with them. Especially IP cameras.
>But I don't see the issue with exposing the HTTP interface to the world?
It's a quick solution, but it is not user friendly.
- What the IP it has is highly dependent on your router config. Even finding the IP requires work from the end user and you, every time. You can tell the router to give the device a static DHCP allocation, sure, but that will break as soon as you switch to a new router.
- Browser changes might break rendering of the config pages.
- The config interface is not standardized: it works for now but it will look outdated a couple of years from now. It can't be improved upon. Understanding and working with it is another annoyance that the user has to learn.
- You need to handle credentials management, which is messy, or you can put nginx or whatever in front and let the proxy handle authentication. The first solution requires a whole bunch of boilerplates on the device and is not secure. The second one is secure, however, it requires you to have control of a nginx server that has to know specifically about your IoT device.
- On a small device, you likely are unable to host and deliver all assets on the device (for example, boostrap). That means you'll have to rely on a third party to deliver those resources for you. It might break in the future.
- Let's say a person wants to know all the params and controls, they have to read your web page source code. They have to tease out UI intermingled with logic.
- All of those is well if you know you'll gonna deploy it at home where you control everything and reconfig it every time you have a new router. But let's say you want to gift it to a friend or deploy to the end users. The amount of work you'll need to setup for that HTTP config thing to work consistently for the friend is a lot. You can't tell him/her "just find the device's IP and go to the website..."
> You can tell the router to give the device a static DHCP allocation, sure, but that will break as soon as you switch to a new router.
All routers have some way of finding out the IP leases.
> Browser changes might break rendering of the config pages.
That's a fault in the browsers.
> The config interface is not standardized: it works for now but it will look outdated a couple of years from now. It can't be improved upon. Understanding and working with it is another annoyance that the user has to learn.
That it stays the same is a benefit, not a bad thing per se, and one could always allow for a simpler set of calls as an API to achieve functionality independent of the design.
The auth problem is definitely an issue, but more so when you expose your stuff to the whole world than to a LAN. It's next to impossible to get this right over the lifespan of a device.
Anyway, I think you really have a valid point but to me it all revolves around the security issues, the remainder depend strongly on your point of view and are not absolutes.
>All routers have some way of finding out the IP leases.
Sure, with 1001 ways of accessing a router's IP leases table varying depending on the manufaturer, user names and passwords, whether anyone has changed the password, where to click, interfaces, apps, avahi daemon, nmap, ipv6, temperature outside, God's mood, and another 1001 ways of screwing it up even you know how it's supposed to work. Try to explain to a non-tech friend (even a relatively IT savvy one) how to find the IP of the Raspberry Pi on the local network and you'll understand why it is a bad idea. If you have client isolation, which some routers and setups have, you're screwed, too.
It's so bad that Google has to have a dedicated app just to find the IP of the Raspberry Pi on the network - I'm not kidding [1]. And that's supposed for the people who are courageous enough to try programming a Pi.
Yeah technically you can do it, but if it's so stupid and flaky that you can't rely on it, then can't be counted as a method to do something.
It's a clock, why does it need config? If you need to adjust the time and light, give it a poti or button for manual adjustment. Might even give it a radio to grab time of the air. Even a sim card to get NTP of the WAN would be simpler than having to connect to it.
I know, I know, you wanna configure the light to flicker as signal for ... failed log in attempts. :)
PS: at least something was realized. I never finished my alarm clock design because LEDs do draw energy, more than would be feasible for battery operation, I thought. Quick check: 2000mAh at 1.5V in an AA cell, 20mA at 1.4V per LED. So, with 100 LEDs like here, I would be swapping Batteries by the hour; And a single LED pulsed at 1/100 s might run for (barely) a year.
This project reminds me of https://www.thelightclock.com/ where the time is displayed by blended colors. Maybe this project could have a similar setting?
I’ve had several strips of these just waiting for the perfect project. Anyone else have any interesting ideas for weekend projects using addressable LEDs?
I had a project on my living room ceiling for a good while. If you stuff the LED strips into PEX tubing (common white plastic plumbing) you get a decently diffuse LED "stick".
I took 8 of these modules, about a meter long each, and hung them from the ceiling in a semi random pattern, mapped them to a 2D plane in software, and used MIDI data from Ableton live to trigger light patterns that would be played across the LED array. Decent party trick.
It unfortunately was mostly destroyed when someone fiddled with the variable voltage supply it was hooked up to in an attempt to turn it off post-party. Word to the wise: if there are knobs on equipment at a party (mixer, lighting, etc), people will inevitably fiddle with them. Design for this.
I built a system that displayed where I am by different color statuses. For example, if someone comes looking for me and the lights are red, I'm not there. Yellow means busy, don't interrupt, rainbow/green means come in.
Controlled by a Raspberry Pi, great for an office or a shared space. I ringed the door with LEDs.
I've built a few weekend-level projects with these.
One I've loved the most is ambient lighting. I ringed the ceiling of one of my rooms with these and I can fade them in and out to a warm or cool white. It is great for hanging out with friends since there's this warm glow coming from all directions. Also great for reading. My next step is to create areas that I can light up sections above chairs and sofas.
It's also fun and easy to attach these to bikes. You can then just ziptie your arduino under the seat or somewhere like that and then light up your frame.
If you have a GPS module, you can build a compass or something that always points to the same spot.
You could also give your sofa and chairs underglow.
Grid-based displays are fun. You can cut the strips and re-arrange them in a "zig-zag" pattern if you don't mind soldering a few wires.
Lately, I was also thinking it could be fun to try 3d-printing some little spherical diffusers for individual 5050 LEDs and arranging individual ones of those in a larger area like a window.
[1] http://www.bramknaapen.com/equinox-clock/