Testing drivers as Windows services

Now that my OpenTherm Gateway is operational, the interface to my Remeha Calenta has become almost obsolete; I could deactivate the whole Calenta driver now, cause the information from the OpenTherm Gateway is enough for me. But just shutting down the Calenta interface is not what I’m going to do – this is a great opportunity to test a driver while it’s running decoupled from the system – as a (Windows-) service.

I already did some small tests some time ago where I compiled a driver to a Console App; within minutes I had one running in my test-environment, but I didn’t go any further than that. And now that things are getting serious,  I decided to jump right to building a driver as a (Windows) service, which sounds like the best thing to do – I don’t see any benefit in having lots of drivers running as a Console App – a Service sounds much better.

So this evening I started reading on how to create a Service in Delphi, cause I’ve never done that before. Well with the TService class you’ve got a service installed in just a few steps.

The first thing I needed was some indicator to make the code service-aware. With all drivers built inside the ‘kernel’, it was very easy to get in- and outgoing data from driver to the event system, device objects, etcetera. That’s all gone when the driver is running as a service. So I had to alter some code so that the driver knows whether it’s running as a service or not; cause if so, it has to use MQTT to publish outgoing data instead of pushing it into a PC queue. Likewise, it has to subscribe to some relevant topics to be able to receive information from the outside world (e.g. the other Domotica system components).

Service-awareness was not that hard; it seems that checking the value of the Application.Mainform property is enough – if it’s nil, it’s safe to assume ‘service mode’ (probably Console mode as well, but didn’t check that).

Creating a MQTT equivalent for those internal queues won’t be that hard either; a single line of code has to be replaced so that the data is being published, instead of queued:

// 20121113
//DistributeToDevice(PhysicalAddress, copy(Buffer,1, PacketSize));

if gRunningAsService
then MQTTPublish(PhysicalAddress,copy(Buffer,1,PacketSize))
else DistributeToDevice(PhysicalAddress,copy(Buffer,1,PacketSize));

I also had to define whether a driver should be started from inside my Domotica system or that it was supposed to be running stand-alone as a service; for that I created an extra field in the driver table so that I wouldn’t end up with 2 running versions of the driver – the embedded one and the service instance.

Right now I have the Remeha Calenta driver running as a service – quick and dirty, just to see what happens and what has to be added and changed to make it reliable and most important: easy to work with.

Calenta Service

All that’s left to do is MQTT-enabling the Calenta driver and I can test this old-code/new-style driver without the fear of information loss, yet test as ‘live’ as much as possible 🙂

Tagged . Bookmark the permalink.

5 Responses to Testing drivers as Windows services

  1. Steel says:

    thnx for the site with all info!

    I just finished my rs232-ttl cable and connected fine with the Recom software to my Calenta.
    I also just read your OpenTherm Gateway site.

    However, what’s not 100% clear for me is, can I also ADJUST my temperature settings with the service RS232 interface? E.g. when I’m away, can I configure the calenta to stay off, and when I’m home earlier, can I configure the calenta to go on earlier? (e.g. with remote desktop on a PC that is connected to the service RS232 interface on the Calenta). Currently it is not important if this is possible with the Recom software or my own created software with a custom protocol.

    Or are these features only possible with your OpenTherm Gateway that is between the thermostat and the boiler with the OpenTherm protocol?

    Reason is, I would like to control the Calenta, but don’t know if this is possible with this service RS232 interface. If not, I have to look at the OpenTherm protocol like you did with the OpenTherm Gateway.

    I have a Calenta with iSense thermostat.

    • Bit off topic, but what the heck 😉
      No, it’s not possible to change the temperature setpoint. There are some things you can adjust though – for that you should have a look at the Recom software, there are some parameters you can change (IIRC).
      For changing the temperature setpoint you’ll need the Opentherm Gateway. Or, (in combination with a Honeywell thermostat with TELE input…) you could use that to change the setpoint to a predefined value. But the iSense looks much better than a Honeywell 😉

      The Opentherm Gateway site is not mine!

  2. Steel says:

    Thnx for the really fast reply!
    I know it was OT, but because this was the latest post about Remeha I replied here. This is going to be OT too, but really curious now about the complete story..

    To be honest, I thought the ‘Opentherm Gateway’ (http://www.tclcode.com/opentherm/index.html) was yours. Who is behind that site and what is your part in it? I cannot find a name on it.

    I thought it was your complete idea/PCB/SW/site.
    Especially because you wrote ‘Yep, I’m going to build a 3rd Opentherm Gateway’ on 7 october..

    I just stepped in the Remeha Domotica this weekend, so I haven’t read all articles of your site, sorry for that.

    Yesterday I checked the OpenTherm protocol myself and quickly read how it worked (voltage/current differences, manchester).. have to think about the next step for me. Maybe I’m going to create the Opentherm Gateway with the information on that site.

    I also read the iSense has 1 input that is configurable (functionality and time). Probably I’m going to use that first before creating a complete Opentherm Gateway.

Leave a Reply

Your email address will not be published. Required fields are marked *