71–80 of 173 posts
Something like ble/lora/zigbee for device-gateway comunication and mqtt or similar for gateway-collector is the best for me.
Earlier quoted context omitted.
Yes, you can isolate individual devices the same way you'd isolate any IPv6 device on your home network - using a firewall. Normally you would firewall away your entire home network and only open up connectivity to the devices you want. Additionally, you can configure the firewall on the Border Router as well, which is the device that actually interfaces between Thread and other networks.
That's a shot in the dark, but I may ask it here: Do you have a simple documentation that would tell someone who knows how to route an IPV4 network and avoid the pitfalls, what is the correct way to do it in IPv6? I struggle to find a good summary of the things one needs to know
HTTP for IOT is super heavy, on one side it may be simpler for developer to hop in, but performance wise this shouldn't be used for anything large scale or where power/bandwidth constrains are an issue. Something like ble/lora/zigbee for device-gateway comunication and mqtt or similar for gateway-collector is the best for me.
The machine the gateway is running on can also be extended to use your solution of choice, for example ZWave with an ESP8266[0][1].
You can also bring your ble/lora/zigbee device-gateway solution with you and have that thing talk to the WebThings Gateway as well, acting as a proxy if necessary.
IMO it doesn't get much better than this -- the ship to have one true communication standard (tm) has already sailed if it was ever even possible, so we're going to have to paper over them if we want devices to interoperate -- whatever does the papering is probably going to be more powerful than the devices themselves, and HTTP has proven to be a pretty easy to grasp and flexible enough interface over them.
All that said, in the lighter-than-http pile of technologies there's also CoAP[2] which I learned about recently that is pretty cool.
[0]: https://github.com/mozilla-iot/zwave-adapter
[1]: https://www.instructables.com/id/Mozilla-IoT-Gateway-With-ES...
Earlier quoted context omitted.
Yes I do, even when I know when I'll get home, plans can change. A timer also can't tell me if my AC is actually on, may fail in the case of a power outage or I may forget to set it, as such using a timer doesn't provide a meaningful improvement over just turning on the AC when I get home and tolerating the heat for half and hour or so. In the end, a timer has no feedback, so a closed loop system will always be bette…
You do realise that power draw likely averages less than 350 watts. Your A/C running for an additional hour or two a few days a month would cost you a dollar or two, max. Given that the load is likely removing peak daytime heat, then sustaining a less-challenging night-time temperature, the net impact is probably even less.
It's not horrible, but that's like half a space heater and most people spring for something bigger.
Earlier quoted context omitted.
You do realise that power draw likely averages less than 350 watts. Your A/C running for an additional hour or two a few days a month would cost you a dollar or two, max. Given that the load is likely removing peak daytime heat, then sustaining a less-challenging night-time temperature, the net impact is probably even less.
The average central A/C will use 4000 to 5000 watts. I own the cheapest smallest window unit at the store and I just checked it's about 600W (4.8 amps @ 120V). It's not horrible, but that's like half a space heater and most people spring for something bigger.
First hour use may approach peak, but again, most of that is incurred regardless.
5 kWh is $0.50 - $1.00, which is the cost of running an hour long for a day, the worst-case scenario. You'd spend a lot more on IoT kit (the Turris Omnia alone is $300) for minimising that cost.
Timers are cheap.
What's HN's thoughts on IoT? To me it looks like yet another buzzword from the "wouldn't it be neat?" crowd (the same people who previously gave us a lot of hype about Semantic Web and P2P social networks) but as before none of the applications are actually worth the hassle, this prevents critical mass from ever being reached, and in reality it's mostly just a way for appliance companies who are already overcharging…
It's a great idea, but companies are building products that no one wants. Here's a few ideas of products / services / suites of items I would actually buy for my home: - Machine to completely do my dishes. End to end. It puts them from the sink to the dishwasher. Runs the dishwasher. Takes them out of the dishwasher and puts them in the cabinet. I do not care if this takes 5 hours - it can run overnight. I just don't…
- Cook a meal from scratch. End to end. Takes the ingredients from the fridge and puts a meal on the table at a specified time. Orders new ingredients when it doesn't have them. Also washes the dishes (see above).
HTTP for IOT is super heavy, on one side it may be simpler for developer to hop in, but performance wise this shouldn't be used for anything large scale or where power/bandwidth constrains are an issue. Something like ble/lora/zigbee for device-gateway comunication and mqtt or similar for gateway-collector is the best for me.
The great thing about HTTP outside of just being well known and available everywhere for developers is that you can use it to negotiate switches to other completely different protocols, or change content types, as necessary. This doesn't do much to help truly resource constrained environments but honestly as power and performance get cheaper, I think most consumer usecases can spare the cycles. The machine the gatewa…
I don't want webdevs coming and breaking the embedded ecosystem. I don't want my fridge crashing because of somebody's webpack setup going haywire.
HTTP for IOT is super heavy, on one side it may be simpler for developer to hop in, but performance wise this shouldn't be used for anything large scale or where power/bandwidth constrains are an issue. Something like ble/lora/zigbee for device-gateway comunication and mqtt or similar for gateway-collector is the best for me.
The great thing about HTTP outside of just being well known and available everywhere for developers is that you can use it to negotiate switches to other completely different protocols, or change content types, as necessary. This doesn't do much to help truly resource constrained environments but honestly as power and performance get cheaper, I think most consumer usecases can spare the cycles. The machine the gatewa…
For sure I applaud this and will play with it. And hope my cynicism is misplaced.
What's HN's thoughts on IoT? To me it looks like yet another buzzword from the "wouldn't it be neat?" crowd (the same people who previously gave us a lot of hype about Semantic Web and P2P social networks) but as before none of the applications are actually worth the hassle, this prevents critical mass from ever being reached, and in reality it's mostly just a way for appliance companies who are already overcharging…
That's my take as well. Complexity for the complexity fetishists among us.
What's HN's thoughts on IoT? To me it looks like yet another buzzword from the "wouldn't it be neat?" crowd (the same people who previously gave us a lot of hype about Semantic Web and P2P social networks) but as before none of the applications are actually worth the hassle, this prevents critical mass from ever being reached, and in reality it's mostly just a way for appliance companies who are already overcharging…
It's a great idea, but companies are building products that no one wants. Here's a few ideas of products / services / suites of items I would actually buy for my home: - Machine to completely do my dishes. End to end. It puts them from the sink to the dishwasher. Runs the dishwasher. Takes them out of the dishwasher and puts them in the cabinet. I do not care if this takes 5 hours - it can run overnight. I just don't…