Earlier quoted context omitted.
And the microphone
And the GPS
[deleted]
I stayed in a hotel with Android lightswitches and it was as bad as you'd think
41–50 of 325 posts
Re: I stayed in a hotel with Android lightswitches and it was as bad as you'd think
#42People forget how reliable and secure things like hard-wired physical light switches and other natural interfaces (like paper books, etc.) are. There seems to be a vast ignorance about topics like reliability, interfaces, usability and design. Just because it's digital, it doesn't mean it's better - I'd argue for the contrary in many cases. I don't want to upgrade the firmware of lightbulbs, I just don't. Despite my affinity for them, I have more than enough computers surrounding me in my everyday life.
Re: I stayed in a hotel with Android lightswitches and it was as bad as you'd think
#43Does anyone have a mirror? It looks like it's been taken down for me.
Re: I stayed in a hotel with Android lightswitches and it was as bad as you'd think
#44Earlier quoted context omitted.
I think they were right to tell you to leave them alone, but a better answer would be: "we'll add them to our backlog (or whatever way you manage issues or work), and get to them by X iteration". As long as you were really working on an MVP and not a version 1.x .
That's technical debt, and it's hard to fix. A prototype, sure, it can have flaws, it's a proof of concept of feature X, not feature X SECURED. But then the release has to be a rewrite. If it's not, those flaws are more likely to become permanent. And when they do begin work on repairing their codebase, they'll spend several times the money and time to fix than if they'd spent some time early on. They'll also likely…
Ok, I'll clarify: I think they were right as long as it was a throwaway prototype. And the GET delete operations are probably a bad idea even for a prototype. I was thinking of a rewrite for release 1.x.
I don't have enough knowledge of the stage the OP's startup was to have answered, so I stand corrected.
Re: I stayed in a hotel with Android lightswitches and it was as bad as you'd think
#45Earlier quoted context omitted.
I think they were right to tell you to leave them alone, but a better answer would be: "we'll add them to our backlog (or whatever way you manage issues or work), and get to them by X iteration". As long as you were really working on an MVP and not a version 1.x .
The problem is those things end up being forgotten or interfaced to in so many places that in the end they become un-fixable or won't be fixed to keep other stuff running. You need to do it right from day #1.
I was thinking more of a throwaway prototype, but the answers on other threads convinced me it wasn't good advice, and I don't know what stage the OP's startup is.
Re: I stayed in a hotel with Android lightswitches and it was as bad as you'd think
#46Earlier quoted context omitted.
Or you could just implement them as-is, earn a shitload of money and then enhance their security in the next version or with a firmware update once you'll have the luxury of investing in R&D. At least it's better if a security-wary entrepreneur implements them instead of someone who simply doesn't give a flying fuck.
No. Bolt-on security doesn't work. It is either possible to do something securely and won't really take significantly more time, or it's not possible to do it securely at all, and no future update is going to fix it.
So why do I bother clicking "install updates" on machine every few days?
Re: I stayed in a hotel with Android lightswitches and it was as bad as you'd think
#47I feel like I'm missing out on a huge bulk of money simply because when I have ideas of "Internet of Things", I cant get over the security obstacles and cancel the ideas. If only I just didn't care (or didnt know) and just implemented whatever the heck brought in money from oblivious customers.
I build stuff like that - my approach is to limit capabilities to the absolute minimum, and anything that is not needed for function but necessary for debug/diagnostics stays on the device rather than going across the network. This limits the devices a fair bit - firmware update across the network with no local interaction is not allowed, nor is accessing the local data store. Want to email me and talk about this?
Which is exactly what a physical switch would do. No wireless internet, no GUI, just a switch.
Re: I stayed in a hotel with Android lightswitches and it was as bad as you'd think
#48KNX, being one of the most sophisticated and proven building intelligent protocol, widely adopted in Europe.
If anyone interested, cross scan its default IP interface port 3671 and, say German telecom ISP IP range (and there is CSV available on www), with efficient penetration test tool like masscan, challenge it with 0x0205, look for 0x0206 on response.
Thousands of home and factories and commercial buildings welcome you with real time datagrams on all their switches/appliances/presences/sensors/cams/... Bonus point: writable!
Re: I stayed in a hotel with Android lightswitches and it was as bad as you'd think
#49I liked how the article gave the commands used to set up the correct networking config with the bridge.
Can anyone recommend a good reference / tutorial for learning basic network-fu in unix ?
Re: I stayed in a hotel with Android lightswitches and it was as bad as you'd think
#50Why on earth are they using Modbus? Is there already some sort of industry standard (on Modbus) for remotely controlling hotel peripherals?