Open Letter to SeedStudio

A while ago I purhcased a couple of relay shields from your site and was recommending them to my project's users . Unfortunately, you discontinued the original product and no documentation, nor any forwarding or upgrade information, is available.

Even though a new version of the product now exists, it is not immediately obvious to my users whether the new product is compatible with the old, and whether it can be used as a drop-in replacement.

Other open hardware manufacturers retain documentation for even discontinued products available indefinitely (example here), because even though the product is discontinued, there are many instances of it in possession, and sometimes open source project maintainers need to support products that they don't have in their hands (such is my case).

It would be much appreciated if you could consider making the documentation for the old version available, and providing version compatibility notes on both old and new devices so people without deep technical knowledge could be sure that the new version of the product can be used instead of old. Including a link to a new device on old device's page won't hurt either.

Thank you for consideration,

--vt

---

PS: The text above was sent to you a few months ago, but there was no response. Since then, it came to my attention that not only relay shield was upgraded, but also the UartSB V2.2, and possibly others. The pattern is obvious - you're upgrading devices as soon as you run out of stock of components you could get for the cheapest price. That's OK, everyone has to make a living. However, if you respect people that make your bread and butter just a tiny little bit more, you might get more respect, which will definitely make your sales better. On the other hand, if you are an uncertainty, you are a risk. If you are a risk, you are a threat. Threating your customers is a bad business strategy.

For now, I will only recommend your products only if there is no other alternative, and a clear link to this post will be included next to recommendation. Your competitors' products will be recommended instead, even if the price is higher. Good luck.

Coming Up: Calendar Integration

You could see some pretty definite hints here, now it's coming to life. So, what exactly is it?

Generic Schedule Updater

ScheduleUpdater interface in dz3-scheduler module provides the interface, and AbstractScheduleUpdater provides the most generic baseline for implementing any back end integration. Want to store your schedule in a flat file? Be my guest. Want to read it off IRC? Anytime.

The updater is injected into the scheduler, so you're pretty much free in what and how you do it. That is, in case if you're not happy with the concrete implementation that will be a part of the release.

Google Calendar Integration

Just like it was planned, DZ will read the schedule from the the calendar of the account of your choice. Both Google and Google Apps accounts are supported, as well as pulling schedule details off any public calendars that you've subscribed to. Basic connectivity has already been implemented, details will be ironed out between now and next release.

SketchUp + Energy Performance, Part 6

(part 1)
(part 2)
(part 3)
(part 4)
(part 5)

OpenStudio Plugin for SketchUp, another brick in the EnergyPlus wall.

${mobile-device} + ${appliance}, Nokia edition

Not sure if this post reached the right audience, so reposting it here:

Nokia released the Control Center - a complete home automation solution.

Here's a video - there's a couple of fragments worth looking at if you're interested in temperature zoning.

I don't have any doubts that this system will be beyond the reach of the majority of readers here, and doubt that partial solutions will be offered (though wouldn't be surprised if this actually happens, I've been trying to show for years that this is quite doable).

Still, it's worth noticing that the big players are finally catching up to the game.

Pulse, Reloaded

Once upon a time, there was an overheating video card. It begat the Pulse project, the hardware health monitor. Later, overheating house begat DIY Zoning, and since its inception, Pulse started to wither away into oblivion - a few years later I marked its status on SourceForge as "inactive", and today, there's not even a web page for it.

However, recent emergence of Android changed a lot. For a long time, lack of hardware support for DZ was a showstopper - nobody wants a zoning system that needs a computer in order to operate it. Smartphone, however, is a completely different deal.

Almost exactly a year ago I started planning for it. A month ago, I got my hands on the hardware. Today, I can say with confidence that G1 can deliver, and it does make sense to implement a control system with a mobile interface based on Android platform.

One of the lessons of DIY Zoning development was that it is a bad idea to have a monolithic system - I had to split it up three or four times before I was happy with the distributed features of the whole system. Not to repeat the same mistake, the application will be more generic than just a zoning system controller.

Hence, hereby the relaunch of the Pulse project is announced.

It'll be a short while before the feature set is established, the project site is again complete with content, and version control system will have the code - I just don't want to release half-baked barely functioning code prematurely, it is still in the works. It's just that privately expressed interest towards the project exceeded the critical mass recently, and I thought you folks would like to know what I'm working on.

Stay tuned.

SketchUp + Energy Performance, part 5

(part 1)
(part 2)
(part 3)
(part 4)

Here's a short entry about Energy Analysis Plugins for SketchUp.

SketchUp + Energy Performance, part 4

(part 1)
(part 2)
(part 3)

I think I'm going to stop referring to HVAC-Calc, lest there be any confusion...

Anyway, the saga continues - and here's the last installment: See your building's energy performance - and note, it's free.




Let the fun begin.

Who Needs A Thermostat?

I've been pondering about this question for a long, long time - starting in about 2001 when the only way to control DZ available was a debug panel, and last time in an essay about SWMBO Compliance Certification (Squeezebox is still a good candidate), but it seems that there's been a new development that might if not put an end to the fruitless search, then significantly widen the options available.

I'm talking about Android.

It remains to be seen how viable the platform is and how many hardware manufactures will jump on the bandwagon. But for now - having worked on different Google APIs (Checkout and Calendar in particular) I can say that it's sure going to be a hell of a fun ride, and I'm about to get busy installing the Android SDK and tinkering with it to see how well can a user interface for a HVAC system work on a cell phone.

Now, who needs a thermostat on the wall, really?

SketchUp + HVAC-CALC, part 3

(part 1)
(part 2)

Now, Official Google SketchUp blog reports that the beta version is available for download.

Hurry before they change their mind.

Google Calendar as external scheduler for DZ???

Just thinking aloud - would using Google Calendar API be a gross overkill or actually a smart idea?

Let me see...

• Unlimited number of zones supported...
• Unlimited number of periods scheduled...
• Arbitrarily flexible scheduling - you want 5+2? We have it. You want 5+1+1? We have it. You want 7-Day? we have it, too.
• Accessible from Internet...
• Accessible from your mobile phone...
  
• Relatively nice and user friendly user interface...
• They even work on improving it while you sleep...

Actually, this may not be such a bad idea at all.

SketchUp + HVAC-Calc = ?

Loosely quoted, "Good companies have many great ideas. Great companies know which great ideas to discard".

Alas, I will not have time to implement this, nor ways to approach the Big Guys to make this happen, but I wonder - am I the only one that sees an obvious symbiosis of SketchUp and HVAC-Calc?

Granted, it's not a five minute project, but all the necessary components are already there - and it won't be that difficult (especially for big guys like Google) to implement a real-time heat loss and gain recalculation as one works on the model of the house...

One of the most important features of SketchUp is that it, being a Google application, evolves fast. Plugins are there, too. It would be really interesting to see where it goes - SketckUp Blog is a nice place to keep an eye on it.

More on SketchUp later - it might have many obvious and not so obvious ramifications on the ways home automation, HVAC and general improvements are done. For example, the most obvious side effect of one creating a house model is that all the hidden spaces you've never thought about become obvious, and the task of routing your cable system becomes significantly less intimidating.

to be continued...

Software Architecture: Centralized vs. Distributed

Evolution of software moves in mysterious ways. Especially if you're not the one contemplating it, but the one making it happen. Hindsight is always 20/20, and now that I'm looking back at the way DZ evolved, I'm seeing that I was merely trodding the same path as countless others - namely, coming all the way from monolithic single host software design to modular distributed.

Just as dinosaurs became extinct, DZ ceased to be a monolith even before it become public - the first GPL'd version was already split in several parts able to talk to each other via TCP/IP, and the parts were linked together in a modular container driven architecture.

Further down the road, the project started shedding more pieces as better versions of them arrived elsewhere (scheduler would be one example). It also became clear that as computers become smaller and cheaper, the day will come when it would be not only possible, but beneficial to utilize multiple computers for a task that could be perfectly done by just one - just for the very reason of having a particular computer in a convenient place for connecting hardware.

Most prominent examples would be -

• An HTPC which has to reside in a rigidly defined place, next to the rest of AV equipment;
• A wireless router that is a focal point of wireless and Ethernet connectivity;
• A workstation, which by itself provides several relevant data streams (CPU temperature, motherboard temperature, hard drive temperature).

Which makes distributed communications difficult to underestimate. Initially, it was just about protocols, now, it's getting all about application interoperability and plugins (Cacti, Munin, Nagios, Mister House to name a few).

Stay tuned.

HVAC Interoperability? Forget about it...

"The Home Plug and Play Specification represents a strong first step towards unifying the industry behind a common open industry specification and accelerating the deployment of smart interoperable devices in the home," stated Kevin Kahn, Director of Intel's Communications Architecture Lab and Intel Fellow. "This will enable new applications for the PC bringing increased convenience and security to the homeowner."

This inspiring quotation comes from a press release dated... January 10 1997. Over 10 years ago.

So, what do we have today?

The Home Plug and Play Specification never materialized.
Same is the fate of CEBus, for all practical purposes.
BACnet, Modbus, and LonTalk never made it down to residential applications.

Up to this day, there is no sign of existence of a unified diagnostic interface across residential HVAC devices.

Only the very advanced and recent systems such as Carrier Infinity have remote access, but even for that you have to pay a hefty $100 annual fee, and it does NOT have a simplest possible thing - the Ethernet interface. Yes, instead of providing an ability to plug a CAT-5 cable into it, it goes across the SkyTel pager network, quote, "because it didn't require a computer network to operate".

Side note: forgive me for being blunt, but I don't really understand why two pieces of equipment, both of which reside in my house, keep nagging for money and require a roundtrip across the world, rely on complicated and expensive infrastructure, absolutely refuse to talk to anything that hasn't been paid for and/or thought of by the designers? Two answers come to my mind:

1. The manufacturers want to milk the customers and make them pay for most number of upgrade modules they can (market segmentation in action, also, see Carrier Infinity vs. Bryant Evolution);
   
2. The designers didn't know about the fact that an Ethernet connector hardware costs pennies to implement and the computer network in a strict sense is not even necessary (hint: static IP, DHCP, zeroconf, Ethernet hub).

You pick the answer you like better.


Let me skip the rest of the long list of arguments that lie just beneath the surface, and state the fact as it appears from a consumer standpoint: Interoperability between commercially available hardware appliances is effectively nonexistent.

One of possible reasons for this is that the residential HVAC industry hasn't reached maturity - technically speaking, we're barely at introduction stage yet. None of the manufacturers seem to have realized that with drastically shortened product development and obsolescence it is much more profitable to play nice together than to rip the sandbox apart trying to get the biggest share of toys.

Related is the fact that the explosive growth of IT, achievements in hardware and software interoperability and the benefits they can yield are mostly being ignored.

Yet another fact is that most probably the manufacturers are stuck in the middle of the hardware development pipeline - and they still can't wake up and realize that unless they manage to shake off the illusion that they can pull it off, cut the losses, drop the pipeline and start working as the present day demands, they will be overrun by smaller, more agile companies that are able to utilize all these nice things referred and alleged to above.

Mark my words.