I am an old electronic engineer. I started programming of micro-controllers (better to say micro processors) in the 1970/80s with simple hex-terminals and two line displays at an Intel 8080 and 8085 or Zilog Z80. My big jump was an Apple 2e with Z80 Softcard and CPM (from a rather small US company called Microsoft). My first big task was to integrate the (very modern !) TEAC drives with 640 kBytes into CPM, instead of the Apple drives with 146 kBytes. Microsoft had sent the sources of CPM to help. My "office software" was WordStar. I programmed new printer drivers to make the changing of different printwheels possible when printing my dissertation. I defined colon-commands for WordStar to synchronize printing and printer handling. There was only space of 256 bytes for custom drivers. Of course, they had to be developed with a macro assembler. Often used branches to the same destination I replaced by preloading the stack (once) and jumping via return (several times), winning two bytes for every jump. And the technical equipment was expensive. I remember the cost of 10.000 DM (2 DM = 1 €) for a 1 MB memory extension of a VAX 750 (our mainframe computer at the institute I worked with).
Times have changed a lot. Sometimes I imagine to have a time machine, taking a modern USB-stick with 128 GB and reading speed of 400 MB/s, and jumping to the past to discuss technology development with my old friends. At that time, the technical features of today were not thinkable. 128 GB in a thimble and 400 MB/s transfer speed would have been so believable like interstellar spaceship jumps to the next galaxy.
In the last decades I experienced a lot of trends and hypes, based on convincing technical details and great promises of the industry. For example the arise of MAP (Manufacturing Automation Protocol) introducing Token Passing Bus for real-time communication and announcing the end of Ethernet. Or the international fieldbus (which led to a standardization of 8 different fieldbus systems with thousands of pages), that promised to make the world of automation cheaper and to save a lot of copper cables. And enabling the plug-and-play of different supplier's devices at the same network (ha, ha, ha).
But Ethernet survived and the problems of bottle necks by bus collision simply vanished because nobody uses Ethernet with a bus. But with tree structures of routers and switches on full duplex lines. No collisions, extremely high speed, and no discussion about the waste of copper and expensive cables.
And WLAN seems to go a similar way, increasing speed, increasing reliability and decreasing prices.
OK, a long introduction for a short view on home automation. I think, the main problem is, that (especially big) companies do not want to be simple device suppliers. They want to create dependencies via networking. There is no interest to present universal usable equipment inter-operating with the equipment of their competitors. And of course there is no interest, that users look behind the curtain of the theater and modify the devices to their local needs or even repair defect devices.
From that point of view, motions like Arduino (and possibly MySensors) are game changers. Meanwhile even big companies support Arduino and open the chance for users (as programmers) to test their own ideas and build an automation world fitting to their local needs.
But the big companies will try to create dependencies wherever it is possible. They promise to make your life more easy, e.g. by presenting pre-compiled (fantastic) libraries, or to make the communication secure with their easy to handle key management. The most simple and effective way for a dependency is, to make the devices (or software and/or software development) depending on a cloud connection.
I can only hope, that users/programmers see the traps and endeavor for their independence.
What we need for home automation is/are
- a communication background, that is simple to handle and provides tools for different applications and new ideas. Like TCP and UDP with IP provided via sockets without any restrictions. (I am using broadcast communication like the CAN bus in cars and I will not use a network, which does not support broadcasting.)
- device suppliers with the interest to provide reliable and reasonable devices for home automation without creating dependencies via clouds or hidden protocols and features.
- developers with new ideas to create a real "smart" home, not only "the big remote control" for television, coffee maker, light modification and so on.
I think, it is a good time for learning and testing, building own devices and improve technologies (and software). Big companies still put their pants on one leg at a time as we do and we should not hesitate to present our ideas and improve our capabilities in fruitful discussions.
Thanks for reading ... and (hopefully) for your comments.
