the recursor home : about : rss : spamgourmet : otherdog studio
animals : anything : elsewhere : food : homeautomation : music : reading : restaurants : tech
 
user-managed home automation 2017-11-05 00:17 UTC
I'm starting a new blog topic - home automation - breaking off from the /tech subject because I think I'm going to be posting a lot about it.

This is the first post in the new topic, but I'll probaby go back and recategorize my older posts in /tech for neatness' sake.

So anyway, I've been picking at home automation for a long time. It's gratifying that some major vendors like Google and Amazon are getting into the market. But (!) I decided to avoid what I'll call 'vendor managed' devices long ago - I want all the data to stay in the house (unless I want it to leave and direct it where to go) and I want to maintain complete, unshared control over all the devices. Can I call that 'blue sky home automation' because, because no cloud - get it?

Anyway - I see the benefits of vendor management - makes everything much easier. Which means the way I'm doing it is much harder.

But then again: Google's Home Mini needed a software patch to stop some of them from recording everything

One drawback of staying out of vendor control is that all the new technology seems to require it - that is, the vendors are no longer taking the time painstakingly expose and document low level access to their devices, because that's not needed when a higher level vendor managed controller is present - this means people like me will increasingly be using older and older technology, unless things change. There are some exceptions, of course, but I just don't think there's much money in the market for non-vendor-managed home automation devices, and so I expect activity to stay low and maybe get lower.

Apple, I believe, is doing it my way (sans the low level documentation), and so hats off to them for that. I'm not using any of their stuff, though - my impression is that it tries to be simultaneously user friendly and very secure - both laudable goals - and so has a much heavier technology lift than the other vendors. So much so, it seems to me, that that their model is too limited for my purposes, at least right now.



And I believe I'm taking things a little too far in some cases - I generally prefer to write my own code down to accessing serial ports on devices rather than use road-tested and completely trustworthy frameworks like Mister House (although I frequently rip off things from that codebase). If I was a technology manager I would have to fire myself for writing a bunch of code that needs to be maintained and never really needed to be written. Thankfully that's not the story here :)

So what I'm not going to do is attempt to package up and release my code - it's way too site-specific (and incomplete - I only implement capabilities when I need them), and there are a bunch of great frameworks out there already. I will instead post about specific devices, techniques, and experiences.
discuss (1) permanent link

smart thermostats suck 2017-11-04 19:10 UTC
I just took down from the wall my second pair of Insteon thermostats. I'm not getting a third pair. I'm pretty sure I know what went wrong with them - each time we had a power outage, presumably with a power spike at the beginning and/or end, the two thermostats would die - the LCD screen displaying giberrish or zeroes and the device non-responsive to the buttons. Resetting didn't help. At first, I thought it might be a fluke, so I bought a second pair. But when they went out simultaneously under the same circumstances, I have to conclude that they have no protection against power surges.

I had high hopes for these. I went to the trouble of running 5 wire thermostat cables from each of my condenser/heater things to replace the 4 wire ones that were there, in order to run these things. I had never gotten around to coding for them - it was a little more complex than I had hoped, and I never was able to put together the time and focus to break through that hurdle - I think it's just that they use extended Insteon messages instead of basic ones, and I haven't yet written the code to support that - lame excuse, I suppose. But the power spike vulnerability seals their fate.

Which leaves me... where? Vendor-connected thermostats seem to be ruling the market - Nest, for instance - but as I mentioned earlier, I'm steering clear of vendor-connected devices where I can, and this is a situation where I would rather have dumb thermostats (like I do right now), than compromise on that principle.

Problem is, I suppose, that the vendor connected thermostats have been going so strong that there's not much market support for local-only smart thermostats. There may be some that are zwave or zigby, etc. (it's true that I have not yet coded any support for these more modern protocols). But I'm thinking instead about keeping the dumb thermostats and wiring those 5 wires (or some of them) to a raspberry pi that also has a relay shield with another 5 wire cable which actually goes to the condenser/heater and controls it. The dumb thermostat would appear to continue to operate normally (important for certain family members...) but in fact would be simply sending its information to the raspberry pi which would in turn echo the commands using the relay shield - as well as doing other things I suppose. I'll try and post updates on that project.
discuss (0) permanent link


Creative Commons License
original works are licensed under a Creative Commons Attribution 2.5 License.

blosxom