Vault-OS : Now BACNet Compatible?

I was working on something really important to me last night - a shim to communicate with the BACNet enabled industrial RS-485 controller for my diesel generator which I recently got secondhand from EBay.

In some ways, this is the reason for Vault-OS. I need to sit in primary at the comms desk and check how much juice is in the batteries in Sparkgap, how much fuel is in the generator and be able to shunt power from solar or wind to the batteries safely while I refill the generator remotely from a pump or it charges the alternate batteries. The other stuff is great, measuring average temperature anywhere or turning fans on and off on a schedule, but the generator/power monitoring is the reason that Vault-OS is really indispensable. It actually supplies the power for all the other systems so it has to be automated in order for anything else to be automated.

While I was working on this little shim (A TSR in PowerBasic to change a Vault-OS network message into a BACNet message and send it along) I had to study the BACNet protocol. I had not really known anything about BACNet, the industrial standard for pooling automation into one collective network. In studying the commands for the shim I would need, I realized I had essentially reinvented half the protocol in Vault-OS, even the basic paradigms for distributed control of things. Looking side-by-side at the translation for the commands, I had things like SEND MANIFEST where BACNET had WHO-ARE-YOU. Where they had READPROPERTY I had GETVALUE in Vault-OS. I had duplicates like this for about 25% of the BACNet standard messaging format for Ethernet which I had put into the Vault-OS operability across mailslots. Where I had a little mini-language in scripted "BASIC" for my controllers, they had BACNet scripts which were roughly the same thing with a few nomenclature differences.

So it hit me.

I didn't need to write a shim so Vault-OS could talk to BACNet. I needed to adapt Vault-OS to use BACNet as it's native messaging format. In doing so, I would open up Vault-OS to almost infinite pluggable appliances in heavy duty environmental controllers and automation devices from anywhere in the world. If I wrote my own BACNet compliant scripting for DOS 16-bit and Windows 32-bit, Vault-OS would go from being a little proprietary closed communications protocol to a system that would comply with the industry standard for automation. Anybody with a copy of Vault-OS would be able to connect up any hardware they purchased with a bit of script as long as it had a BACNet interface, which almost everything does nowadays.

For example, I have PCI Calibre boards for I2C which run utterly different drivers than my calls out to I2C via the Dallas TSR/Win32DLL. I had not really thought through how I would connect up anything that wanted I2C but did not use my basic approach. I assumed I would write shims for different equipment as it became necessary. On the other hand, the Calibre board comes with a BACNet driver for Windows on the CD. All I had to do was write a little script in BACNet for the logic of what I wanted it to do and it would be running within minutes. It's actually easier to make my TSR/DLL code BACNet compatible and assume that is only one of many approaches a person might use in Vault-OS to connect to I2C sensor grids. This is the reason that BACNet has become the industry standard for environmental control and automation.

I have updated the Vault-OS site to reflect this development and consider this a refactor which will probably turn out to be the smartest move I have ever made for the code.

As of last night I had a very crude BACNet script engine running for Win32 which I will put up screenshots this weekend on the Vault-OS site.