3 ms·

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

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.

jimmies 8y ago
>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..."
- jacquesm 8y ago
  > 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.
  - jimmies 8y ago
    >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. 1: https://play.google.com/store/apps/details?id=com.google.android.apps.aiy&hl=en_US https://play.google.com/store/apps/details?id=com.google.and...
posterboy 8y ago
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.

jimmies 8y ago

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

jacquesm 8y ago
> 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.
- jimmies 8y ago
  >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. 1: https://play.google.com/store/apps/details?id=com.google.android.apps.aiy&hl=en_US https://play.google.com/store/apps/details?id=com.google.and...

posterboy 8y ago

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.