A giant 360 LED clock
mathieupassenaud.fr
mathieupassenaud.fr
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.
https://hackaday.com/2016/05/27/minimal-mqtt-control-and-cli...
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.
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..."
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.
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.
1: https://play.google.com/store/apps/details?id=com.google.and...
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.
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…
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.
Also worth noting for the curious that it's very easy to host your own, e.g. via Mosquitto.
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.
http://craigdorety.com/objects.html
Once upon a time I made a project with a similar aesthetic, but not quite as much function (ie it wasn’t a clock):
Do you power your LEDs and Raspberry Pi separately, or do you use the same power supply?
Might be a good start for creatives without coding background as it is a Visualjockey Gold plugin.
Controlled by a Raspberry Pi, great for an office or a shared space. I ringed the door with LEDs.
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.
The tree could be wrapped with the LED strips then the position of the LEDs was obtained using a camera (as they pulse out an ID).
I then created a little Flask app, that ran on the same Raspberry Pi which controlled the LED strips, which let people paint the tree via a website.
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.
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.
One small quibble: why is the /bright endpoint a GET? GET should never have side effects. :)
I had not heard about this kind of addressable LEDs but now I'm inspired to think of my own projects.