On the road again and IO bound no more

Okay, weird title but that is what happens when I try to get cute. Recently I was looking for an SSD to use with a Raspberry PI for my TCF Home Automation presentation in March . It would need to work with USB 2.0, not a huge amount of storage, just local sqlite and logs files basically, and it need not be very fast at all. I found what I needed, that was both inexpensive and met my requirements. In my search I kept running across very expensive SSD PCIe bus adapters. Because of the cost I ignored them. But then I came across this ACM article called: Non-volatile Storage - Implications of the Datacenter's Shifting Center While data centers don't seem very important when talking about HA it actually will be in some ways. What goes for the larger systems tends to eventually get into the smaller systems. And with the IoT that's a lot of smaller things. I'm guessing that it could mean that we'll see more cores and better IO in our HA/IoT devices. I worry about many things related to this kind of architecture. Things like service longevity, reliablity, security, privacy and the need to for being 'always connected'. I really don't see Comcast, Verizon or any of the other providers making that affordable. But we're still moving towards everything being in the cloud. My preference is towards more local control and I'm betting the compromise will be a hybrid. Well that's my predictions for the New Year.

How not to build a home automation empire

My recent Camera blog entry got me to thinking (yes I know, always dangerous). What is really needed to get the HA/smart home/IoT really going with the consumer? Well I can quickly tell you what won't work (always easy to do), bad software! The immediate problem I had with the camera was that the only thing that could use the camera was my smart phone. I couldn't install it on my Android table, weird! And the app was painful to use (big picture, little screen, I'm just not sure how well this plan was thought through). Yes we are going in that direction where the cell phone is central to everything but I found I couldn't use it with anything other than the meshare app. I couldn't get the data (images/video) into any other shared service and it seemed pretty clear that it wasn't going to work with anyone else's products. I would be trapped into vendor lock-in. While I'm no fan of the cloud it is the direction we're going in, so working with existing cloud services is important. I don't need a new service for each appliance in my house. Now what was the password to the refrigerator? And you need to work with other devices. I don't need to be accessing a dozen different apps so I can check the weather, irrigation and the HVAC. HA is a suite of products and services. So if you are building the next big thing in the IoT put a lot of thought into integrating other popular cloud services such as IFTTT and perhaps think about providing an API so that that makers of the world can add things you haven't thought of. By making your products and service interoperable with other products and services (that also interoperate with other services and products) you're more likely to last longer than the flash-in-the-pan devices we're seeing. Oh and also make your products and services work. Insecure, buggy devices and services won't cut it either.

At the moment there are plenty of 'knick-knack devices' and very few 'wow that's useful devices'. With the integration of cloud services that could change but not until the industry changes its attitude. The short life span and up-selling by discontinuing a product or service has to cease. The reason no one likes Microsoft's phones is that they have a bad habit of upgrade by dropping support. Remember WinCE? Those that purchased those devices wish they hadn't. A lesson they quickly learned not to repeat.

The central premise of the maker movement is being able to take one thing add something else (usually something with software) and making something else. Give into that movement and I expect you'll end up with a better product.

IP Camera's and Linux

During the Christmas rush I mistakenly ordered an IP, Wireless, HD camera without too much investigation. When it arrived I suddenly realized that I hadn't checked if I could pull down the images with any of my HA software. What was I thinking?! Anyway, long story short. I can't get at the images directly. These camera's are meant to be used with a cell phone (not a tablet) or the web service. So I used their app, setup the camera, broke out nmap and later started searching the net for any details I could. Nmap found ports 23, 80, 8000 and 9000. My search for the Funlux Mini WiFi 720P HD (or CH-S1A-WA or ZH-IXY1D) camera brought me to a bunch of information such as telnet using root and no password (and no direct way to change that). The web page login is admin/111111. It needs IE because it uses a cab file (wouldn't work with Firefox). I used Wireshark to figure out what was going on and noticed that my WiFi SSID and the access password were being sent in plain text. And that the camera was sharing information (probably video and audio) with a web site on the internet. WOW! I don't know what to say other than I am not happy with this in so many different ways. The picture is great but other than that I can't say anything good.

For those looking to hack the camera, take a look on Hackaday, the link is called Zmodo - Local Controller. A bunch of us posted the various information we've found there. I've also put my notes up on my web page as Hacking a Funlux IP Camera.

Now despite this I'm going to keep the 2 cameras I have. I've already blocked them from internet access and I'm working on securing the telnet access. I'm also going to write some software so I can pull back the images to my HA server. While I can't trust the vendor and their software I should be able to still make use of the cameras. I have plans for a Raspberry Pi loaded with a script to grab the images and video and make them available via a stream so programs like ZoneMinder can access the cameras.

Left floating?

In theory, things will work on the first try. In reality, theory is a nice concept. ;-)

One hard learned lesson, a lesson learned a long time ago, was the need to sometimes have pull-up, pull down resistors or both for some circuits. When things are left floating they may work in one place and fail completely in another or work for a time and later fail. I learned this when working on my first microprocessor design. The board sometimes worked when left alone but always worked after I grabbed the board to inspect it. It usually continued to work after the inspection. Seems that some habits like grabbing a board a certain way, done consistently would be enough to get the floating circuits into the correct state to allow it to work. These kinds of problems are tough to figure out. To make matters worse is when you are working with a 3rd party board and it has these kinds of problems. My MQTT code works well on the W550io boards but only sometimes works on the W5200 shield. Yes, there are code differences but I'm pretty sure I've eliminated that as the source of my problem (voodoo software, bad juju). A quick search of the internet didn't show any useful clues. Poking around in the libraries wasn't useful either (man the Arduino IDE hides way too much). After much trial and error I noticed 2 things. First if I wanted to use the W5200 shield I needed to have the SD card in, even though I'm not using it. And the second thing I noticed was that the w5200 worked perfectly when I added my bus pirate to the SPI circuit. This usually is a pretty good indicator that the pins need some kind of pull-down or more likely, pull up resistor. I'm pretty sure I'll need to set the appropriate port settings to add that or if worse comes to worse, add some resistors to my test boards.

I originally wrote this on 12/23/15 and it has been 11 days since I attached the bus pirate and the circuit has been stable. The software, not so much. I think it has a memory leak. I'll work on that.