IoT Bluetooth Autogate using Modbus

The IoT Bluetooth Relay Board tests well enough with a simple python script, but every time the script finishes bluetoothctl drops its connection to the HC-06. When you run the test script again, it reconnects to the HC-06 well enough, but the connection takes a variable number of seconds, and sometimes the script fails to connect. For an application like the autogate this is not acceptable.

However if the script does not exit the connection is reliable over many days, so the script should not exit. That means a server (Linux daemon) process, and its accompanying client script. There is one such python solution and that is pymodbus, a python implementation of Modbus client and server.

Modbus for an autogate? Modbus is a popular industrial communications protocol. Isn't that overkill?. It probably is.

Or is it? As we have seen the remote sensor/actuator portion is done using bluetooth device and a Microchip PIC18F14K50, which consumes 10mA at 5V. Modbus lives on the IoT gateway, ie the bluetooth master which happens to be an old laptop running Slackware Linux. Pymodbus makes my homebrew autogate remote opener compatible with IoT for Industry. The client python script will then be run by a PHP script from the laptop's apache webserver, in the same way as the Raspberry Pi Robot platform.

Security is via the WPA WiFi password on my home WiFi router. Notice that this system will still work without a broadband connection, as long as your smartphone is within range of the WiFi. The HC-06 will not accept a second bluetooth connection once it is paired to the laptop, so access is via the WiFi alone. With a ADSL connection this is a true IoT, able to accept commands from the Internet.

Remote autogate operation may make sense if you say, want to let the gardener into the yard, or the electricity/water utility person to read the meter. In my case my dogs will probably terrorize the meter reader   before galloping off to poop in the neighbour's yard. So its main advantage is an extended-range autogate remote.

The installation for Slackware is probably subject for another post, but say you had it installed. There is a sample program pymodbus-master/examples/common/updating-server.py which we can use as a template.

The first few lines of code are important:
#---------------------------------------------------------------------------#
# import the modbus libraries we need
#---------------------------------------------------------------------------#
from pymodbus.server.async import StartTcpServer
from pymodbus.device import ModbusDeviceIdentification
from pymodbus.datastore import ModbusSequentialDataBlock
from pymodbus.datastore import ModbusSlaveContext, ModbusServerContext
from pymodbus.transaction import ModbusRtuFramer, ModbusAsciiFramer

#---------------------------------------------------------------------------#
# import the twisted libraries we need
#---------------------------------------------------------------------------#
from twisted.internet.task import LoopingCall

Next we import our bluetooth module, which shall look suspiciously like our previous python test script.

#---------------------------------------------------------------------------#

# communicate with bluetooth rs-485 pic18f14k50 2017-12-19

#---------------------------------------------------------------------------#

import autogate_bluetooth

The main server loop code is simply; we will add our bluetooth code later:

#---------------------------------------------------------------------------#

# define your callback process

#---------------------------------------------------------------------------#

def updating_writer(a):

    ''' A worker process that runs every so often and

    updates live values of the context. It should be noted

    that there is a race condition for the update.

    :param arguments: The input arguments to the call

    '''

    log.debug("updating the context")

    context  = a[0]

    register = 3

    slave_id = 0x00

    address  = 0x10

    values   = context[slave_id].getValues(register, address, count=5)

    values   = [v + 1 for v in values]

    log.debug("new values: " + str(values))

    context[slave_id].setValues(register, address, values)

Next there is our Modbus database, which we reduce from 100 to 16 to reduce memory usage, a initialize to 0 (except for the 2 bits reversed logic for the Arduino relays):

#---------------------------------------------------------------------------#

# initialize your data store

#---------------------------------------------------------------------------#

store = ModbusSlaveContext(

    di = ModbusSequentialDataBlock(0, [0]*16),

    co = ModbusSequentialDataBlock(0, [True, True, False, False]*4), # True because relay logic reversed

    hr = ModbusSequentialDataBlock(0, [i for i in range(16)]),

    ir = ModbusSequentialDataBlock(0, [45]*16))

context = ModbusServerContext(slaves=store, single=True)

Jumping to the end of the file for now, we have:

if __name__ == "__main__":

  #---------------------------------------------------------------------------#

  # run the server you want

  #---------------------------------------------------------------------------#

  looptime = 0.2 # 

  loop = LoopingCall(f=updating_writer, a=(context,))

  loop.start(looptime, now=True) # initially delay by time

  StartTcpServer(context, identity=identity, address=("localhost", 5020)) #2017-12-19

Note the loop time has been speeded up from 5s to 0.2s. StartTcpServer() is set to use the non-root network port 5020, which our client script will need to listen to.

That is all there is to it. Most of the pymodbus server code is done. Now for that bluetooth code in ./autogate_bluetooth.py, which I have put in the same directory so that it imports correctly. Here it is in full:

#!/usr/bin/python

import serial

from time import localtime, strftime, sleep

'''

Sends bluetooth rs-485 PIC18F14K50 commands and receives the replies.    

Usage:

import autogate_bluetooth.py

  ./autogate_bluetooth.py             to test

  Uses pyserial module

  The ems command is single-char, reply is a double sequence of 3 binary bytes

  followed by check strings

  Replies to 'z' are 2 3-byte analog input readings. 

'''

port1 = serial.Serial('/dev/rfcomm0',timeout= 1) #2017-12-19 HC-06 bluetooth   

print 'Waiting for bluetooth connect ...',

sleep(8) # Wait for bluetooth to connect

print 'Done'

cmd = ['z', '1', '2', '3', '0' ]

ChkStr1 = 'HCM'

ChkStr2 = 'LJP'

import struct

import binascii

def check_frame(reply):

  if reply[2:5] != 'HCM':

    print 'Checkbyte HCM Fail', reply

    return 0

  if reply[7:10] != 'LJP':

    print 'Checkbyte LJP Fail', reply

    return 0

  return 1

def ParseReply(reply):

  Battery_Voltage=int(format(ord(reply[0]), '02x'), 16)*256 + \

                  int(format(ord(reply[1]), '02x'), 16)

  Calibrated_Battery_Voltage = Battery_Voltage * 13.75 / 689

  PIC_Voltage=int(format(ord(reply[5]), '02x'), 16)*256 + \

              int(format(ord(reply[6]), '02x'), 16)

  Calibrated_PIC_Voltage = PIC_Voltage * 13.75 / 689

  return [int(format(ord(reply[0]))), int(format(ord(reply[1]))), \

          int(format(ord(reply[5]))), int(format(ord(reply[6]))) ]

  #return [Calibrated_Battery_Voltage, Calibrated_PIC_Voltage] 

def Send_Cmd(cmd):

  # sleep(1)

  port1.write(cmd)

  port1.flush()

  reply = port1.read(80)

  if reply != "":

    print 'Reply:', reply, 'len', len(reply)

  # for j in range(0, len(reply)):

  #   print format(ord(reply[j]), '02x'),

  # print '...'

    if (check_frame(reply) != 0):

      data = ParseReply(reply)

    else:

      data = 0

  else:

    print '... Noreply to cmd', cmd

    data = 0

  return data

import sys

# main program loop

if __name__ == "__main__":

  if (len(sys.argv) == 2):

    Send_Cmd(cmd= sys.argv[1])

  else:

    for i in cmd:

      answer = Send_Cmd(i)

      print 'result', answer

  port1.close()

The main function here is Send_Cmd(). The PIC18F14K50 has been programmed to accept the commands 'z' (read voltages), '0' (both relays on), '1' (first relay on), '2' (second relay on) and '3' (both relays off).

Now let us go back to updating_server.py so we can modify the main server loop to communicate with the HC-06. We need to add a new module update_output() to read the Modbus database. If there is a change (caused by the client script requesting the Arduino relay to turn on) it will then send the correct command to the HC-06. The code is:

import struct

def get_muxoutputBuf():

    register = 1      # digital output (modbus 'coils')

    slave_id = 0x00

    address  = 0

    values   = context[slave_id].getValues(register, address, count=8)#from 48

    # print 'values=', values

    return values

def get_muxscratchBuf():

    register = 1      # use holding registers for convenience

    slave_id = 0x00

    address  = 0x0008

    values   = context[slave_id].getValues(register, address, count=8)

    return values

def set_muxscratchBuf(values):

    register = 1      # use holding registers for convenience

    slave_id = 0x00

    address  = 0x0008 # used as scratch buffer

    context[slave_id].setValues(register, address, values)

    return values

def update_output(a): # new function 2016-08-10 09:15

    #context = a

    str = 'z'

    log.debug("Checking the output buffer")

    scratchBuf = get_muxscratchBuf()

    #print 'scratchBuf', scratchBuf

    outputBuf = get_muxoutputBuf()

    #print 'outputbuffer', outputBuf

    data = [0]*1

    #print 'data length', len(data),

    # pack the bits into the integer/byte array 2015-08-23

    for i in range(0, len(data)*8):

        j = i / 8

        k = i % 8

        # print 'j', j

        if outputBuf[i] == True:

            data[j] |= 1 << k

        else:

            data[j] &= ~(1 << k)

    datastr= [format(data[i], '02X') for i in range(0, len(data))]

    str = datastr[0][1] # 2017-12-20

    #print 'data is',data,'datastr',datastr,'output Cmd data string', str

    if (scratchBuf != outputBuf):

        autogate_bluetooth.Send_Cmd(str) # 2017-12-21 note answer is not stored

        print 'Hey, it is here!!!!'

        print '!!!!!!!'

        print '.......'

        print 'setting scratchBuf to', outputBuf

        set_muxscratchBuf(outputBuf)

        print 'scratchBuf', scratchBuf

    '''

    else:

        print 'scratchBuf', scratchBuf,'outputBuf', outputBuf

    '''

    return str

Next there is the code to update the Modbus database with the raw values read from the HC-06. These are the 2-byte values from the analog inputs. There are two inputs that makes 4 buyes in total.

def update_database(context, answer=[]):

    ''' Updated 2017-12-21

    raw = []

    for byte in answer:

      raw += byte

    print 'raw =', raw

    '''

    register = 3 # input register. *Not* 4

    address = 0; # 2017-12-20

    values   = context[0x01].getValues(register, address, count=4)# 2017-12-20

    print 'stored values=', str(values)

    log.debug(str(address) + " input register values: " + str(answer))

    print 'address=', address, ' answer: ', answer

    #context[0x01].setValues(register, address, raw) # 0x01 replaced slave_id

    context[0x01].setValues(register, address, answer) # 0x01 replaced slave_id

    return

battery_scan_interval = 3600 # set at 1 hour

The new server loop now becomes:

def updating_writer(a):

    global battery_scan_interval

    # read battery voltage every hour

    if battery_scan_interval == 3600:

        answer = [0*2] # 2017-12-19

        answer = autogate_bluetooth.Send_Cmd('z') # 2017-12-20

        if answer != 0:

            print '\n\n Cmd z, voltages are', answer

            update_database(context, answer)

            CPU_Voltage = answer[0] * 256 + answer[1]

            Calibrated_CPU_Voltage = (CPU_Voltage * 5.0) / 1024

            Battery_Voltage = answer[2] * 256 + answer[3]

            Calibrated_Battery_Voltage = (Battery_Voltage * 13.53) / 652

            print 'CPU', answer[0] * 256 + answer[1], 'Battery', \

                  answer[2] * 256 + answer[3]

            print 'CPU', "{:4.2f}".format(Calibrated_CPU_Voltage), \

                  'Battery', "{:4.2f}".format(Calibrated_Battery_Voltage),\

                  'Volts',strftime("%Y-%m-%d %H:%M:%S", localtime())

        else:

            print 'no answer'

        battery_scan_interval = 0

    else:

        battery_scan_interval += 1

    str = update_output(a) # 2017-12-20

And that is it. You run the server from a command line (remembering to run bluetoothctl and 'rfcomm bind /dev/rfcomm0' first) :

$python ./autogate_server.py

Waiting for bluetooth connect ... Done

Reply: ûHCM¥LJP len 10

 Cmd z, voltages are [3, 251, 2, 165]

stored values= [1, 2, 3, 4]

address= 0  answer:  [3, 251, 2, 165]

CPU 1019 Battery 677

CPU 4.98 Battery 14.05 Volts 2017-12-28 17:09:54

... Noreply to cmd 9

Hey, it is here!!!!

!!!!!!!

.......

setting scratchBuf to [True, False, False, True, True, False, False, True]

scratchBuf [True, False, False, True, True, False, False]

Reply: ÿHCM§LJP len 10

The client script is much simpler. Let's call it autogate_client.py. You only use the TCP/IP version:

#---------------------------------------------------------------------------#

# import the various server implementations

#---------------------------------------------------------------------------#

from pymodbus.client.sync import ModbusTcpClient as ModbusClient

You connect to the server thus:

client = ModbusClient('localhost', port=5020)

client.connect()

import sys

from time import localtime, strftime, sleep

if __name__ == "__main__":

    if len(sys.argv) == 2 :

        if sys.argv[1] == 'open' or sys.argv[1] == 'close' \

           or sys.argv[1] == 'Open' or sys.argv[1] == 'Close':

            coils = [True, False, False, False, False, False, False, False]

            rq = client.write_coils(0, coils, unit=0) # 2017-12-20

            print sys.argv[1], 'autogate'

            sleep(1);

            coils = [True, True, False, False, False, False, False, False]

            rq = client.write_coils(0, coils, unit=0) # 2017-12-20

        elif sys.argv[1] == 'ajar' or sys.argv[1] == 'Ajar':

            coils = [True, False, False, False, False, False, False, False]

            rq = client.write_coils(0, coils, unit=0) # 2017-12-20

            print sys.argv[1], 'autogate'

            sleep(1);

            coils = [True, True, False, False, False, False, False, False]

            rq = client.write_coils(0, coils, unit=0) # 2017-12-20

            sleep(2);

            coils = [True, False, False, False, False, False, False, False]

            rq = client.write_coils(0, coils, unit=0) # 2017-12-20

            print sys.argv[1], 'autogate'

            sleep(1);

            coils = [True, True, False, False, False, False, False, False]

            rq = client.write_coils(0, coils, unit=0) # 2017-12-20

        else:

            # python rocks! evaluate argument as python expression

            coils = eval(sys.argv[1])

            rq = client.write_coils(0, coils, unit=0) # 2017-12-20

            print 'writing', coils

        rr = client.read_holding_registers(0,4,unit=0x01)# 2016-12-20

        #print "read_holding_registers 1", rr.registers

        #print "read_holding_registers type", type(rr.registers)

        #print "read_holding_registers list data type", type(rr.registers[0])

        CPU_Voltage = rr.registers[0] * 256 + rr.registers[1]

        Calibrated_CPU_Voltage = (CPU_Voltage * 5.0) / 1024

        Battery_Voltage = rr.registers[2] * 256 + rr.registers[3]

        Calibrated_Battery_Voltage = (Battery_Voltage * 13.53) / 652

        print "read_holding_registers 1", rr.registers, 'CPU', \

              (rr.registers[0] * 256 + rr.registers[1]), 'Battery', \

              rr.registers[2] * 256 + rr.registers[3]

        print 'CPU', "{:4.2f}".format(Calibrated_CPU_Voltage), \

              'Battery', "{:4.2f}".format(Calibrated_Battery_Voltage),\

              'Volts',strftime("%Y-%m-%d %H:%M:%S", localtime())

    else:

        print 'Wrong/no arguments', len(sys.argv)

The main code is:

            coils = [True, False, False, False, False, False, False, False]

            rq = client.write_coils(0, coils, unit=0) # 2017-12-20

You set the bits you want (only the first 2 are implemented) and use client.write_coils() to write to the Modbus database. The server process does the rest. 

Typical output is:

$python ./autogate_client.py open

open autogate

read_holding_registers 1 [3, 251, 2, 62] CPU 1019 Battery 574

CPU 4.98 Battery 11.91 Volts 2017-12-28 16:14:06

To close the autogate you run the client again:

$python ./autogate_client.py open

open autogate

read_holding_registers 1 [3, 251, 2, 62] CPU 1019 Battery 574

CPU 4.98 Battery 11.91 Volts 2017-12-28 16:31:13

Now when I am on foot I find it useful not to open the gate wide, as a dog might then be tempted to bolt. This opens a man-size opening by triggering the relay twice:

$python ./autogate_client.py ajar

ajar autogate

ajar autogate

read_holding_registers 1 [3, 251, 2, 62] CPU 1019 Battery 574

CPU 4.98 Battery 11.91 Volts 2017-12-28 16:31:07

And that is all there is to it. Now for the PHP script.

$cat  ~/autogate/bluetooth/html/autogate.html 

   <!-- \/ starthtml -->

<html>

 <head>

   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

   <META NAME="keywords" CONTENT="Heong Chee Meng electronics engineer system sof

tware hardware digital design analog design FPGA VHDL parametric tester Windows N

T realtime device driver Linux kernel hacking semiconductor manufacturing SCADA e

mbedded Seremban Malaysia KM48T02 DAC71">

   <META NAME="description" CONTENT="Heong Chee Meng's Autogate Remote Control website.">

   <META NAME="author" CONTENT="Heong Chee Meng">

   <TITLE>Heong's Autogate Remote Control Website</TITLE>

 </head>

Heong's Autogate Remote Control Website

<p>

<p>

<p>

<p>

<p style="float: left; width: 33.3%; text-align: "center>

<form action="openbutton.php" method="post">

  <button type="submit" name="open" value="Connect"><img width="360" height="360" alt="Connect" src="./open.svg" align="left"></button> 

</form>

<p>

<p>

<p>

<p>

<p style="float: left; width: 33.3%; text-align: center">

<form action="openbutton.php" method="post">

  <button type="submit" name="ajar" value="Connect"><img width="360" height="360" alt="Connect" src="./ajar.svg" align="right"></button>

</form>

<p>

</BODY>

</html>

<!-- /\ end html  -->

And the PHP script is:

$cat  ~/autogate/bluetooth/html/openbutton.php 

<html>

<body>

<article>

<?php

  if (isset($_POST['open'])) {

    $result = shell_exec('python autogate_client.py open');

    echo "Done!<pre>$result</pre>";

  }

  if (isset($_POST['ajar'])) {

    $result = shell_exec('python autogate_client.py ajar');

    echo "Done!<pre>$result</pre>";

  }

  header("Location: ./autogate.html");

?>

</article>

</body>

</html>

Aim your browser (I used Google Chrome) at the webserver: xx.xx.xx.xx/autogate/autogate.html and there you have it- an IoT bluetooth Autogate remote. 

Happy Trails

IoT Bluetooth Relay Board for Autogate

Clockwise from top: Arduino dual relay, LM2956 boost-buck DC-DC converter, bluetooth USB PIC18F14K50 and HC-06 bluetooth module

The IoT Autogate is simply a combination of two systems, the remote-controlled Autogate and the Bluetooth Solar Battery Voltmeter. with the addition of a cheap (only RM10) Arduino dual-channel relay board.

Arduino 5V opto-isolated dual relay PCB

The PIC18F14K50 (it is really an incarnation of the Microchip Low Pincount Development Kit)  can drive the optoisolator input directly using two of its spare pins configured as digital output. Best of all the relay coil consumes little power: 80mA per active relay. When it is not active the power used is 10mA at 5V or 0.05W. This is very useful because in the event of a power cut and the autogate is running on battery, you want the gate to remain powered for as long as possible.

The relay board logic is reversed, that is a 'low' or 0V output by the PIC18F14K50 turns the relay on. I happened to have the pins RC4 and RC5 free so I used them. This is the same port as the voltmeter's analog input pins (RC6 & RC7).

I first tested it from the USB port of my laptop. This lets me start testing from a clean USB Microchip Low Pincount Development Kit software and helps prevent errors in my bluetooth code from affecting the relay board code. It is safer to use a USB hub, preferably one which has its own 5V power in case a wiring mistake damages your laptop.

First of, simply set TRISC correctly for both analog inout and digital output:
    #define mInitAllLEDs()      LATC &= 0xC0; TRISC &= 0xC0;
If you need to delve further into this code you first need to read the (rather thick) PIC18F14K50 datasheet.

We put a little veneer of C over the new analog output bits:
    #define digital_output_1    LATCbits.LATC4 // 2017-12-03
    #define digital_output_2    LATCbits.LATC5 // 2017-12-03

So, to turn both relays off (like on power up) we simply do:

    digital_output_1 = 1; //Make sure relays are off

    digital_output_2 = 1; //Make sure relays are off

I simply added a counter to the USB code and wrote the value of the counter to the PIC18F14K50 output port. The first time a voltmeter command is issued, only one relay comes on (01). The second command causes the first relay to go off and the second relay to come on (10). The third command causes both relays to go off (11). The forth command causes both relays to come on (00).

The actual test is simplicity itself (python rocks!) and took just a few minutes. The relays duly clicked in their assigned order:

$python
Python 2.7.11 (default, Mar  3 2016, 13:35:30)
[GCC 5.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import serial
>>> port=serial.Serial('/dev/ttyACM0', 19200, timeout=1)
>>> port.write('z');port.read(20);
1
'\x00\x03HCM\x00\x00LJP\x00'
>>> port.write('z');port.read(20);
1
>>> port.write('z'); port.read(50);
1
'\x02/HCM\x01}LJP\x00'
>>> port.write('z'); port.read(50);
1
'\x03\xd1HCM\x03eLJP\x00'

Now with the new digital output function working it is time to test it with the bluetooth code. To do so I needed to power on from a non-USB 5V. Otherwise the PIC18F14K50 would detect the USB port and would not run the bluetooth code. This is easily done with a power bank.

 

As before, use hciconfig and bluetoothctl.

[bluetooth]# devices
[bluetooth]# paired-devices
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# scan onm
Invalid argument onm
[bluetooth]# scan on
Discovery started
[CHG] Controller C8:FF:28:27:7D:2C Discovering: yes
[NEW] Device 98:D3:32:20:BB:7B HC-06
[bluetooth]#
[bluetooth]# agent on
Agent registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]# pair 98:D3:32:20:BB:7B
Attempting to pair with 98:D3:32:20:BB:7B
[CHG] Device 98:D3:32:20:BB:7B Connected: yes
Request PIN code
[agent] Enter PIN code: 1234
[CHG] Device 98:D3:32:20:BB:7B UUIDs: 00001101-0000-1000-8000-00805f9b34fb
[CHG] Device 98:D3:32:20:BB:7B Paired: yes
Pairing successful
[CHG] Device 98:D3:32:20:BB:7B Connected: no
[bluetooth]#

Then 

$rfcomm unbind /dev/rfcomm0 98:D3:32:20:BB:7B 1

$rfcomm bind /dev/rfcomm0 98:D3:32:20:BB:7B 1

Back to python (did I say python rocks?)

$python

Python 2.7.11 (default, Mar  3 2016, 13:35:30)

[GCC 5.3.0] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> import serial

>>> port=serial.Serial('/dev/rfcomm0', timeout=3)

>>> port.write('0');port.read(100)

1

'\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x0

3\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xf

bHCM\x009LJP\x03\xfbHCM\x009LJP'

>>> port.write('1');port.read(100)

1

'\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x0

3\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xf

bHCM\x009LJP\x03\xfbHCM\x009LJP'

>>> port.write('2');port.read(100)

1

'\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x0

3\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xf

bHCM\x009LJP\x03\xfbHCM\x009LJP'

>>> port.write('3');port.read(100)

1

'\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x0

3\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xf

bHCM\x009LJP\x03\xfbHCM\x009LJP'

>>> port.write('0');port.read(100)

1

'\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x0

3\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xfbHCM\x009LJP\x03\xf

bHCM\x009LJP\x03\xfbHCM\x009LJP'

>>>

Finally, I needed a 12V to 5V DC to DC power supply. The autogate runs off a 12V backup battery, and while I could wire to the autogate controller's 5V (it is also a Microchip) that would mean soldering two wires to every time I changed controllers. Again Arduino provided the answer: the LM2596 module that cost RM3.50 on sale.

Do power it up and set the output before you connect it to your PIC18F14K50, for the LM2596 is a step-up (boost) as well as step-down (buck) converter. The trimpot is multiturn, so it might take a bit of turning to get it down to 5V. Hook it up to the PIC18F14K50 and we are ready to mount it into the autogate

You can go faster and jump right to the bluetooth section, but I find while these methodical baby-steps may take a little longer, it sure beats two weeks of confusion while you sorted out the interacting bugs from hardware build, digital output code and bluetooth code. 

Perhaps you can spot the bug in my code, which I will address in the next post. 

Happy trails.

Autogate: remote-control Gate

Autogate: control panel on far left. Note the swing-arm actuator anchored to the bottom of the gatepost

A couple of years ago, we had a remote-control gate installed. Known here as an autogate, it is quite popular, can be retro-fitted and is and not too expensive. The parts are available here online.

It gave no trouble for a year or so, then all of a sudden it would open on its own. Things got a little fraught because at about the same time, the wife had rescued three street dogs, and they would get out and fight with about six other dogs up the road.

Naturally we rushed up the road to get them back in, but they figured we had come to fight the good fight, and not only routed the other dogs but were having a grand time chasing them down and were in no mood to come home.

I had the repairman in and he fixed it, but within a month it opened again. This time I had a different repairman in and he swapped out the controller board and the power transformer. Within six months a lightning bolt hit the gatepost and you guessed it: it opened the gate. Luckily a rainstorm followed and the dogs did not fancy getting wet so we were spared the dogfight.

So I thought it is about time I got up close and personal with that autogate.  It has two swing-arm actuators which was mounted to the bottom of the gates and anchored at the gateposts. When 12V DC was fed to it, it contracted to open the gate or extended to close it.

The controller board has a Microchip controller which operated the relays that powered the actuators. It has two inputs, which when shorted to 0V, opened both gates or just one gate.

Top right: autogate controller. Top left:12V transformer

Power was via a 12V transformer, which the controller board also rectified and generated the 12V for the actuator, 5V for the Microchip CPU and 13.8V DC to charge a 12V sealed lead acid backup battery.

Remote operation is via a separate radio receiver, which takes in 12-15V and when the transmitter buttons are activated will put out a low impedance on its two output lines. Match these lines to the inputs of the controller and you have an autogate system.

12Vdc Actuators

The controller board is RM250, the transformer RM25, the remote control module is RM100. The actuators are about RM250 apiece, depending on the stroke length. For less than RM1000 including labor, you can get an autogate fitted.

Wired up controller board

But what about the problems? The first cause were ants. There are loads of them all over the garden. I find them very useful - get an ant colony living in the roots of your tree and they will keep the termites from eating the tree alive from the ground up. A year after the autogate was up, we had a very wet rainy season. The ants got used to walking along the gates (they are normally shut anyway) to avoid the runoff rainwater.

The control panel was nice dry and warm: ideal way station for wet ants. Trouble is, sometimes they shorted the remote control outputs. A shorted remote is a 'gate open' signal. The first repairman did a warranty repair - he replaced the damaged controller board and sealed up the panel door with sealant.

When the problem recurred, the next repairman found the ants had returned via the air vents in the panel. This time he put in some mothballs and sealed the panel again. Things were fine until the lightning strike, which blew out the fuze and the battery charger circuit.

I got tired of calling autogate repairmen - they are nice people and have reasonable charges, but they are never on time. Their idea of an appointment is sometime within a week. Besides, it is about time the gate got permanently fixed. Or so I thought.

Autogate controllers: Super i (left) and S-1 (right)

Since the controller boards were cheap at RM190 or so I bought a couple. They are different makes but all work the same way. I did not really choose them - they are simply the same ones the repairmen used. I just swapped the boards out when there is a problem. After a while I found it was quite easy to repair them, so I ended up with four boards, two spare, one in service and one a parts carcass.

The wife found the solution the the lightning problem: she simply found the circuit breaker to the autogate panel and turned it off when a rainstorm looked likely. Over the years we developed a routine- the broadband, satellite TV, telephone and autogate got disconnected before a storm and reconnected after.

The last rainy season was so wet water went into the sealed-up panel anyway and soaked the transformer into a leaky sorry mess. This I solved by bagging up the replacement in a freezer bag before remounting it. For good measure I duct-taped a bin liner over the whole panel. Not pretty, but a green bin liner kind of disappeared into the hedge next to the panel.

Problems solved, right? Well, kind of. We finally trained the dogs not to rush out whenever the gates opened (actually each dog was convinced only after she got caught in a closing autogate). We soon learned it was easier not to stand by the gate when it was being opened- the dogs tended not to bolt. Unfortunately this meant operating the remotes right at the limit of their range. Even so it was tolerable until we had a record wet season this year.

Heavy rains soaked the ground year round, and the remotes range decreased a lot. Plus I had been messing about with bluetooth Microchip PIC18F14K50 controllers. The range was so good the webserver in the study could reach the bluetooth PIC18F14K50 at the gatepost!

It is time to upgrade a bluetooth-equipped PIC18F14K50 to output to the autogate controller. With a PHP script in the webserver (my WiFi extended a few meters beyond my gates) we can then use our smartphones as an autogate remote. This will also make it an IoT device. Since my bluetooth PIC already read analog inputs I might as well include a battery voltmeter function.

Stay tuned for the next post the IoT Autogate. Happy trails.