A proper Premise driver must be composed of objects from Premise's comprehensive framework. In other HA programs, you can model a digital input as a boolean value (TRUE=ON, FALSE=OFF) or, if you have a group of inputs, as an array of boolean values. You can model a temperature sensor as a numeric value. You could write a driver in this fashion within Premise but it would not be a proper driver because you can't bind to it.
In Premise, programming logic and drivers are two separate and independent layers. You can write and test logic without drivers. When you are satisfied the logic works correctly, you bind it to an appropriate driver.
In Premise, the existing DigitalInput class is used to model a real-world digital input. A collection of DigitalInput objects would represent a group of digital inputs. Premise's framework contains a slew of useful classes including DigitalOutput, Button, TemperatureSensor, HumiditySensor, Dimmer, Power, etc. A proper driver is composed of these core classes. If your Premise Home contains a Relay, Pump, or Fountain object, you can bind it to a driver that contains a DigitalOutput object. You can't bind it to a driver with a boolean value or an array of boolean values.
I'm helping Dinki develop a proper Weeder Technologies WTDIO-M driver. So far, I have written the basic framework of required objects: a single RS-232 port can support multiple WTDIO-M modules and each module supports 14 channels where each channel can be defined to be either a DigitalInput or a DigitalOutput object.
Now I need to do the real heavy-lifting, namely parsing the data communications. I have the documentation but I'll be flying blind because I don't have a WTDIO-M board to test. Dinki has agreed to debug the driver and I invite anyone else with a WTDIO-M module to participate in this collaborative venture.
You'll need to install DebugView on your Premise PC to see the debugging messages my driver will generate.
The attached images show the WTDIO-M driver's UI.