the recursor home : about : rss : spamgourmet : otherdog studio
animals : anything : elsewhere : food : homeautomation : music : reading : restaurants : tech : update
iaqualink down 2018-04-04 16:22 UTC
Well, I was ashamed to admit it, but I do have one entirely vendor managed automation device, and that's the "iAqualink" pool controller module that manages all the devices that make our pool work - the pumps, the lights, the valves, the heater, the salt chlorine generator, etc..

The iAqualink device is a black box on my local network - it starts up, gets an IP address via DHCP, and then sets up a back channel for clandestine communication to the iAqualink cloud service. To control it, I use their phone app or website to interact wtih the cloud service and send/receive data to the device. The device that sitting right here on my home network...

Anyway, I happily used the system for almost 4 years now without much to complain about other than the principle of the thing, and my inability to integrate it into my larger system. But as of yesterday, their cloud service has been down -they took it down for a 3 hour maintenance window yesterday morning, and it hasn't been back up since. As a consequence, I don't have much control over my pool (I do have some, but it's pretty stone-age button pushing on the main panel).

Anyway - case in point, concerning the dangers of vendor-managed home automation devices, and this is even without the privacy concerns. I'm looking into alternatives. They will all cost hundreds of dollars at a minimum, plus a bunch of my time (I don't mind the time part - I actually insist on it of course). But at least it can be done, or apparently it can. I wish I would have had the presence of mind to address this when the pool was installed in 2014.

permanent link

Radio Thermostat Company of America - CT50 2018-03-15 13:01 UTC
I got the Radio Thermostat CT50 thermostats in and they were very easy to set up on a private-not-internet-connected network, and then access via their well documented RESTful HTTP API. There's no security at all, but that doesn't matter because of where they are. I'm not sure how to set up security, but maybe it's possible.

Getting them working with the rest of the system was very easy. I didn't use the perl module I mentioned earlier because I decided to go down one level and use a REST client perl module in order to access more API calls than the dedicated module exposed. I guess I should really extend and propose changes to the dedicated module - maybe soon. Anyway, the main thing that was missing for me was the function to set the date/time on the thermostat - something that drove me batty with the Insteon thermostats. It was very easy to do on the CT50 -- but really you only set the day of the week, the hour, and the minute. This means that they can be close to a minute off after you set them (if you set them at say, 09:59 at 09:59:59, then the real time changes to 10:00:00 one second later, the thermostat will be 59 seconds behind. Whatever)

Like most thermostats, they have a "heat" mode and a "cool" mode - like some, they also have an "auto" mode that will choose either heating or cooling as needed. Right now I'm simply in "cool" mode because it's kind of hot outside here. Adapting my simple user interface to include the complexity of the thermostat is kind of tricky. I added a command for "cooler" that takes the current temperature, subtracts 2 (with a floor) and then sets a temporary target on the thermostat to that new temperature -- the otherway with "warmer" - but it's not always obvious whether it will be necessary to switch the mode or not to comply with the request. I guess I'll figure that out later, and maybe just wind up in "auto" all the time.

The thermostats are programmable on a weekday basis and I don't plan to create a user interface to do that on my phone - I'll just use the existing touch screen interface for that part.

RTCOA bucks my initial gloomy prediction about home automation - you *can* offer a device with user-friendly vendor cloud-based management *and* have it easily function on a private-only network and hook into a custom user-controlled system. Totally crushing on them right now.

permanent link

more on thermostats 2018-03-06 22:50 UTC
So... I'm still thrashing on thermostats, but today I feel optimistic about the Radio Thermostat CT50 - so much so that I ordered two of them off Amazon. The company publishes an API that is locally callable over http, and I don't believe it's necessary to have them connect to the vendor (although it's possible). There is even a perl module in CPAN for the API. I feel sort of stupid for not seeing these earlier. I will post an update once I have them installed. I plan to create a dedicated WIFI network that does not have internet access and put them on that.

I also looked and (and ordered and received) a permanent link

mycroft 2018-02-19 14:37 UTC
Seeing all the marketing for voice assistants - e.g., Amazon Echo, Google whatever it is - made me feel apprehensive that I was missing out on something - but what, really? (besides having a blatant corporate spy sitting in my house -- I know probably our phones are already listening and watching everything, but at least I can pretend that they aren't)

I already have a smart phone "app" for my home automation/security system that works pretty well (it's really a web page that has special tags that facilitate it looking and acting like an app on android and ios, including being accessible via its own icon).

The app uses client certificates for authentication and it loads up all the available devices and camera feeds, then creates pages based on each "area" of the house that expose the associated devices and camera feeds and let you get status and send commands by swiping or context menus. It's so site-specific that it doens't makes sense for me to post the code, but if anyone wants, I can drill down on the architecture.

Beyond that, we have some computers sitting around to do web searches on, etc., and in our exercise room, I have an iPad that integrates with the elliptical machine and can play music on some bluetooth speakers in the room. We don't have a "whole house" audio system, but then again, the voice assistants don't give you that automatically - maybe Homepod does.

Anwyay. I found out about a voice assistant called "mycroft" that is based on open source software and "open source hardware" - the "mk i" unit I have includes both an arduino (definitely open source) and a raspberry pi (mostly open source - but it has wifi and I'm not sure that part is). The company operates via kickstarter drives. I didn't have to read much before I ordered a mark i unit (which I received within a few days) and signed up for 3 mk ii units through the active kickstarter - those won't be around for at least a year, I guess.

The mycroft lets you write your own "skills" - key - and makes it very easy to do so. You can just ssh in and make a copy of an existing simple one, and start changing it. They strongly encourage you to use their git repository for your skills in order to increase the library of available skills for the community - of course that's laudable, and I'm totally going to do it once I start writing stuff that would work in any place other than right here.

The mycroft skills api (and everything else) is written in python - which I don't know, but is pretty easy to pick up. Since my home system uses Zero MQ transported json messages to do everything, it was very easy to write a skill for - zmq has great python support (better/easier than perl, truth be told), and json is pretty much core to python - it was really just a matter of plugging into the local messaging environment and loading up the names of all the house devices and commands - only took a couple of hours to get working, and that includes several false starts that would not have occurred if I had known what I was doing.

I ran into my first "natural language processing" (NLP) quirks almost immediately. In my system, I name each device with something descriptive, and eliminate spaces - so for instance the "living room light" would be called "livingroomlight" - I don't have a great reason why I eliminate the spaces, other than habits dating back to the 90s. Anyway, "livingroomlight" isn't a word, but "living room light" is three words. So when I tell the myrcoft to "turn on livingroomlight", the NLP function hears that as "turn on living room light" - and if I have merely loaded up the list of names from the ZMQ environment, there's no match, and mycroft doesn't know what to do.

So for now I have a locally stored list of device names where I went in and added spaces, then, after it matches a voice command to a device name, my "skill" removes the spaces in the device name before sending the command through the ZMQ layer so that my system will know what it's talking about. This works fine, but it's a maintenance problem because if I add or change a device name, I'll have to remember to update the mycroft's local list. I have no such issue with the rest of the system - the app and all the other stuff in the house pick up changes automatically. When there are several mycrofts in the house, this maintenance issue will be a pain.

I either need to just add spaces to the names (probably best) or add new fields to the configuration for the devices to include space delimited aliases for the mycroft to use. Or -- I could somehow add the compound-word device names to the NLP lexicon so that they would get interpreted properly by the processor, but that strikes me as a fool's errand, because it seems like I would be undertaking to maintain my own lexicon and would have a lot of trouble with device updates.

Anwyay - at the moment I'm viewing voice assistants as just another new user interface. A good one, to be sure, and I love not having to be holding a phone or sitting at a computer to do stuff. The mk i mycroft is a prototype, though, and the microphone is not great, so you pretty much have to have your face right in front of it for it to hear you. Also, my 11 year old daughter has to use a really low voice - like she's mocking a man voice - to activate the wake word, funny. But I suspect that these things will be better with the mk ii units and with config tweaking.

The mycroft *is* vendor-connected by my definition, but apparently doesn't need to be - certain configuration parameters can be set up on their website and zapped into your unit (which you associate with your account by typing in a code that the unit displays on initial start up -- total vendor connection). I'll be looking into ways to break that connection, but: 1) it doesn't seem at all nefarious, and it's focused solely on configuration, and 2) I can see how it would be basically necessary for someone who doesn't want to SSH in order to configure the device.

permanent link

antiques 2018-01-28 15:56 UTC
I decided to find and order some optional components for my aging (but fully functional) DSC security panel, and I can only find them on ebay as "New Old Stock" -- haha.
permanent link

next 5 entriesprevious 2 entries

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