Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A giant 360 LED clock

mathieupassenaud.fr

Post reply on HN
Print view View original

11–20 of 30 posts

Re: A giant 360 LED clock

#11

Post by jimmies »

arcbyte wrote: post #10
jimmies wrote: post #9

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-…

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..."

Re: A giant 360 LED clock

#12

Post by deathanatos »

jimmies wrote: post #9

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-…

> 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…

Re: A giant 360 LED clock

#13

Post by Scaevolus »

deathanatos wrote: post #12
jimmies wrote: post #9

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-…

> 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…

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.

Re: A giant 360 LED clock

#14

Post by [deleted] »

deathanatos wrote: post #12
jimmies wrote: post #9

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-…

> 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…

[deleted]

Re: A giant 360 LED clock

#15

Post by anfractuosity »

spdustin wrote: post #2

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?

https://www.anfractuosity.com/projects/painting-a-christmas-... - I created a little system to 'paint' my Christmas tree using these addressable LEDs.

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.

Re: A giant 360 LED clock

#17

Post by jimmies »

deathanatos wrote: post #12
jimmies wrote: post #9

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-…

> 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…

>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.

Re: A giant 360 LED clock

#18

Post by asteli »

spdustin wrote: post #2

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.

Re: A giant 360 LED clock

#20

Post by posterboy »

arcbyte wrote: post #10
jimmies wrote: post #9

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-…

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.

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.

Post reply on HN