Configuration

To get started with immediateC, get the source files from GitHub: https://github.com/JohnWulff/immediatec.

Once you cloned the repository go to the directory ./src and run the command ./configure.  This will create a Makefile that can be run later on.

Next, make sure all required Perl modules are installed.
So, first go to the section Using immediateC on Linux Mint 21

After the above is done, continue with the below.

Once the Makefile is created, run the command ./m -I.  This will create a sudo user. 
Then run the command ./ m -a.  This will create and install all the necessary applications and libraries, such as:

• immcc: the C compiler

• immac: the C compiler when immedate arrays are used (see documentation of iC)

• immax: 

• libict.so.1.3.7: dynamic library needed by immediateC

• libict.so.1: a link to libict.so.1.3.7

• libict.so: a link to libict.so.1.3.7

• libict.a: static library needed by immediateC

Note: both libict.a as well as libict.so are candidates to be used by - in this case - immediateC.  It all depends how the application is built: does it link against a .so library or against a .a library?

Note: if Tk.pm is not installed yet on your system you will get compilation errors like this:

Can't locate Tk.pm in @INC (you may need to install the Tk module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0 /usr/lib/x86_64-linux-gnu/perl5/5.34 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.34 /usr/share/perl/5.34 /usr/local/lib/site_perl) at -e line 1.

BEGIN failed--compilation aborted at -e line 1.

Therefor, you need to install this Perl module first.  To do this pls. read the section below called Using immediateC on Linux Mint 21, section iClive on what to do, won't repeat it here.

All should be fine now.  However... See section "First application"

Reusing an old laptop

Under a huge pile of dust I found an "old" HP laptop from 2012 (or was it 2013?) which I wanted to (re)use as a Linux machine (needless to say Windows was installed on that PC).

I used Ubuntu 22.04 LTS for a while but it was slow.  Really slow...  The specs of the laptop weren't that super (not a lot of RAM, not a super fast Intel processor, not a lot of HD size,...).

After some time, I gave up on Ubuntu 22.04 and I wanted to try out Lubuntu since that is much more suited for retired laptops and/or PC's.  At least, it seems so if I read all info on the internet about what Linux distro is best for old hardware.

So, I gave it a try and I also wanted to make sure I could use it for immedateC.

After downloading the .iso file and using rufus 4.3 (as of this writing) to create a bootable USB stick with the Linux distro on it I reinstalled my laptop with this distro.

After the installation completed and I did a full upgrade it was time to start installing all necessary apps and libs to be able to compile immediateC.

Below is, in timely order, the commands to be executed:

• sudo apt install git (looks like this one was already installed)

• sudo apt install build-essential (to get compilers and the whole make mechanism in place)

• sudo apt install libx11-dev (needed later on for immediateC)

• sudo apt install libpng-dev (same reason)

• sudo apt install flex 

• sudo apt install bison 

• Install rlwrap: sudo apt install rlwrap
  Why?  When I'm on the cpan console window then the arrow up/down keys result in awkward signs: ^[[A when pressing the arrow up key, for instance.
  Starting cpan using rlwrap (readline wrapper) solves this issue.
  This can be done both as a regular user or as root:

  • rlwrap cpan 

  • sudo rlwrap cpan 

• sudo cpan (perl was also installed by default, version 5.34.0)

  • First see if the latest CPAN is installed:

    • install CPAN 

    • reload cpan 

  • install YAML 

  • now quit cpan (type exit on the command line)

• sudo cpan 

  • o conf init pushy_https 

    • answer "yes" to the question

  • o conf commit 

  • install CPAN::DistnameInfo 

  • install Term::ReadKey 

  • install Term::ReadLine::Perl 

  • install Term::HiRes (required by immediateC to have accurate timers)

  • install Tk.pm (this will take a long time and at the end, during the test phase, different UI widgets will pop up for a short time)

  • quit cpan 

• cpan (yes, this time as regular user, not as sudo)

  • install X11/Protocol.pm 
    This is necessary to give another meaning to the X of iCbox: 

    • when clicking the X, both iCbox as well as the iCserver(s) will be destroyed

    • when clicking shift-X then only iCbox will be destroyed and the iCserver(s) will stay alive

• Recently, I also had to install Net::MQTT::Simple on one of my RPi's since iCmqtt is using this perl module.
  To install it, on the command prompt, I ran the command cpan Net::MQTT::Simple and all was fine.
  Since iCmqtt will also be called from a systemd service later on, it's best to install this module also as root:
  sudo span Net::MQTT::Simple

• Note that I had issues installing X11::Protocol on one of my RPi's (reason still unknown).  

I had the following error while installing it:

cpan[3]> install X11::Protocol

Running install for module 'X11::Protocol'

Checksum for /home/pi/.cpan/sources/authors/id/S/SM/SMCCAM/X11-Protocol-0.56.tar.gz ok

Scanning cache /home/pi/.cpan/build for sizes

............................................................................DONE

Configuring S/SM/SMCCAM/X11-Protocol-0.56.tar.gz with Makefile.PL

Checking if your kit is complete...

Looks good

Generating a Unix-style Makefile

Writing Makefile for X11::Protocol

Writing MYMETA.yml and MYMETA.json

  SMCCAM/X11-Protocol-0.56.tar.gz

  /usr/bin/perl Makefile.PL -- OK

Running make for S/SM/SMCCAM/X11-Protocol-0.56.tar.gz

cp Protocol/Ext/XFree86_Misc.pm blib/lib/X11/Protocol/Ext/XFree86_Misc.pm

cp Protocol.pm blib/lib/X11/Protocol.pm

cp Protocol/Connection/Socket.pm blib/lib/X11/Protocol/Connection/Socket.pm

cp Protocol/Ext/DPMS.pm blib/lib/X11/Protocol/Ext/DPMS.pm

cp Protocol/Constants.pm blib/lib/X11/Protocol/Constants.pm

cp Protocol/Connection.pm blib/lib/X11/Protocol/Connection.pm

cp Protocol/Connection/INETSocket.pm blib/lib/X11/Protocol/Connection/INETSocket.pm

cp Protocol/Connection/UNIXFH.pm blib/lib/X11/Protocol/Connection/UNIXFH.pm

cp Protocol/Ext/RENDER.pm blib/lib/X11/Protocol/Ext/RENDER.pm

cp Protocol/Ext/XC_MISC.pm blib/lib/X11/Protocol/Ext/XC_MISC.pm

cp Protocol/Ext/SHAPE.pm blib/lib/X11/Protocol/Ext/SHAPE.pm

cp Protocol/Ext/BIG_REQUESTS.pm blib/lib/X11/Protocol/Ext/BIG_REQUESTS.pm

cp Keysyms.pm blib/lib/X11/Keysyms.pm

cp Auth.pm blib/lib/X11/Auth.pm

cp Protocol/Connection/UNIXSocket.pm blib/lib/X11/Protocol/Connection/UNIXSocket.pm

cp Protocol/Connection/INETFH.pm blib/lib/X11/Protocol/Connection/INETFH.pm

cp Protocol/Connection/FileHandle.pm blib/lib/X11/Protocol/Connection/FileHandle.pm

Manifying 16 pod documents

  SMCCAM/X11-Protocol-0.56.tar.gz

  /usr/bin/make -- OK

Running make test for SMCCAM/X11-Protocol-0.56.tar.gz

PERL_DL_NONLAZY=1 "/usr/bin/perl" "-Iblib/lib" "-Iblib/arch" test.pl

1..3

ok 1

ok 2

Protocol error: bad 15 (Name); Sequence Number 17

 Opcode (45, 0) = OpenFont

 at test.pl line 96.

make: *** [Makefile:874: test_dynamic] Error 255

Lockfile removed.

  SMCCAM/X11-Protocol-0.56.tar.gz

  /usr/bin/make test -- NOT OK

//hint// to see the cpan-testers results for installing this module, try:

  reports SMCCAM/X11-Protocol-0.56.tar.gz

Failed during this command:

 SMCCAM/X11-Protocol-0.56.tar.gz          : make_test NO

I have no clue as to what the above means but I could resolve it by installing the module without the testing facilities (I really don't care about this feature):

cpan -T X11::Protocol 

This installed the module without problems.

Installing XRDP (X11 remote desktop protocol)

To be able to do Remote Desktop Connections from Windows one more package need to be installed.

• sudo apt install xrdp 

• sudo systemctl enable --now xrdp 

• sudo ufw allow from any to any port 3389 proto tcp 

Now open Remote Desktop Connection from Windows, give the IP address of the laptop and you should see an intro screen asking for the user name and password.

Once given, a connection between Windows and Lubuntu will be established and you can work on Windows in your Lubuntu environment.

As always, the first application is a kind of "Hello, world" when trying out a new environment.  This is no different now.

To build such an application, start the immediateC editor by launching the command iClive.

Next, create a project directory and create a new file into that directory: hello.ic (must end with .ic!)

Add the following content to it:

%{ #include <stdio.h> %}

if (IX0.0) {

printf("Hello, immedateC world!\n");

} else {

printf("Goodbye, immedateC world!\n");

}

So, whenever IX0.0 is true then the first printf will be executed.  Else, the second printf will be executed.

Press the Build button in the iClive IDE: the result will be a failure.  The error will look like this:

$ iCmake -fsAd200 hello.ic 2>&1

hello.c

hello

/usr/bin/ld: cannot find /usr/local/lib64/libict.a: No such file or directory

collect2: error: ld returned 1 exit status

gcc compile errors in 'hello.c' - no executable 'hello' generated

ERROR: 'hello' cannot be built from 'hello.ic' (return = 1)

The problem is that the linker looks at location /usr/local/lib64 (see red above) to search for libraries to link against, since Linux Mint 21 is a 64 bit system.  However, the libraries are located in /usr/local/lib instead when running the sudo make install command (see first section First things first...).

The solution to this is quite simple (don't know if this is the right way to go, but it anyhow works): make (if necessary) a lib64 directory and copy the libict* files into this directory:

• cd /usr/local

• sudo mkdir lib64 (only if needed!!!)

• cd lib64

• sudo cp ./lib/libict* .

This way, the libraries are also available in the /usr/local/lib64 directory and this time the build will be successful!

Few experiences later...

The above way of working is NOT the way to go.  Normally, the autoconfig tool should know if it configures for a 32 or 64 bit system and act accordingly.  But Linux Mint 21 running on a 64 bit system doesn't seem to "understand" this, since it only puts the libict* libraries in /usr/local/lib and it even doesn't create a /usr/local/lib64, let alone putting the libict* files in it.

One possible solution is the following (again, not sure if this one is the right way to go):

./configure --libdir=/usr/local/lib

When running this it looks like the system is doing its job fine.  If you then run sudo make install the libict* libraries are stored in both /usr/local/lib as well as in /usr/local/lib64 (even if that last directory would not exist: it will create it for you!).

No idea why adding the --libdir parameter is also copying the libraries in to /usr/local/lib64, but it works...

Application + auto-activate iClive

./bar -l: will start the bar executable and also the iClive environment.

Compiling an app with iCmake

iCmake -zsAf bar.ic: will compile bar.ic with extra debug information so that everything what's happening internally is seen on the terminal.

Starting iClive

To start iClive when starting an application you can also add the -l option like so:

iCserver \

       -R iCpiI2C -f -d300 \

    QX140,0xFF \

    QX830,0xFF \

  ~IX831,0xFF \

  -R ff_ic -l \

  -v ff_ic.vcd

Mdiff

Mdiff is something John made himself.  The difference between diff and Mdiff is that Mdiff can do different diffs at the same time.

Example command
Mdiff kLel Test0/ORG/*.*: will show the differences between the original code and the compiled code

The below information is an excerpt from John Wulff's great immediateC application to control PLC's in a very efficient way.

IEC-1131 base names are as follows:

                   <io_op><size_op><address>

                   <io_op>

                   I data is input to an iC control client.

                   Q data is output from an iC control client.

                               - the following are for debugging clients only

                   C debug data is output from an iC control client to iClive

                   D debug data is input to an iC control client from iClive

                               - more details for C and D in section 5.

                   <size_op>

                   X signifies 8 bits of single bit data.

                           bit addresses are not used in the registration or

                           transmission of X senders and receivers. 8 bits are

                           always transmitted as 1 byte and the clients insert

                           or extract modified bits as necessary.

                   B signifies 8 bits or 1 byte of numerical data.

                   W signifies 16 bits or 2 bytes of numerical data.

                   L signifies 32 bits or 4 bytes of numerical data.

                   H signifies 64 bits or 8 bytes of numerical data.

                   <address>

                   This number is the numerical IEC-1131 address. Each

                   data type QX, QB, QW, QL and QH as well as IX, IB, IW,

                   IL and IH has its own address space, which is a sparse

                   array.  The numbering of each of these address spaces is

                   independent of the others and continuous.

                   Some hardware I/O drivers may have a common address

                   space which may also enforce word, long word and long

                   long word baundaries.  Checking for such boundaries

                   and overlap of I/Os with different word length has been

                   implemented for iC apps but is normally not switched on.

                   This does not affect iCserver either way.

               NOTE: the syntax of correct IEC-1131 base names is only checked

               by iCserver for equivalence declarations. All other IEC_1131

               base names are received from clients where they should have

               been checked.

               Examples:

               SIX0    8 single bits IX0.0 to IX0.7 sent from an external source

               RIX0    8 single bits IX0.0 to IX0.7 received by an iC controller

               SQX9(7) 3 single bits IX9.0 to IX9.2 sent from an iC controller

               RQX9(7) 3 single bits IX9.0 to IX9.2 received by an external sink

               SIB10   single 8 bit byte IB10 sent from an external source

               RIB10   single 8 bit byte IB10 received by an iC controller

               SQB15   single 8 bit byte QB15 sent from an iC controller

               RQB15   single 8 bit byte QB15 received by an external sink

               SIW10   single 16 bit word IW10 sent from an external source

               RIW10   single 16 bit word IW10 received by an iC controller

               SQW15   single 16 bit word QW15 sent from an iC controller

               RQW15   single 16 bit word QW15 received by an external sink

               SIL10   single 32 bit long IL10 sent from an external source

               RIL10   single 32 bit long IL10 received by an iC controller

               SQL15   single 32 bit long QL15 sent from an iC controller

               RQL15   single 32 bit long QL15 received by an external sink

               SIH10   single 64 bit long long IH10 sent from an external source

               RIH10   single 64 bit long long IH10 received by an iC controller

               SQH15   single 64 bit long long QH15 sent from an iC controller

               RQH15   single 64 bit long long QH15 received by an external sink

When running iClive on the Raspberry Pi Zero I alwasy got the following warning message:

pi@rpi-zerow:~/mystuff/immediatec/src $ iClive bar.ic

perl: warning: Setting locale failed.

perl: warning: Please check that your locale settings:

LANGUAGE = (unset),

LC_ALL = (unset),

LC_ADDRESS = "nl_BE.UTF-8",

LC_NAME = "nl_BE.UTF-8",

LC_MONETARY = "nl_BE.UTF-8",

LC_PAPER = "nl_BE.UTF-8",

LC_IDENTIFICATION = "nl_BE.UTF-8",

LC_TELEPHONE = "nl_BE.UTF-8",

LC_MEASUREMENT = "nl_BE.UTF-8",

LC_TIME = "nl_BE.UTF-8",

LC_NUMERIC = "nl_BE.UTF-8",

LANG = "en_GB.UTF-8"

    are supported and installed on your system.

perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").

To  solve this, add the following to the file /etc/default/locale (as sudo):

LC_CTYPE="en_GB.UTF-8"
LC_ALL="en_GB.UTF-8"

This should solve the issues.

To compile immediateC from scratch, do the following:

• Get latest update from GitHub

• Run a make distclean

• Run ./configure from within the ./src directory: this will make sure the Makefile will be generated for Windows or Raspberry Pi (very important!!!)

• Run m -I: change to root

• Run m -a: this will recompile everything and also do the installation part

• If only installation is needed, run m -i instead.

• make distclean: remove all generated targets

• configure: run/create Makefile from the Makefile.in template

• m -clSi: start compilation with the following parameters:

  • m: compile with debug information so traces are visible in iClive (generated "assembly" also visible)

  • cl: build immcc and create static library libict.a with debugging support

  • S: create shared library libict.so but without debug support

  • i: install everything

• m -X: build iCpiI2C and dependent components (e.g. MCP23017.c)

• m -zX: same as above, but the compilation process shows all the steps taken (verbose-alike approach).

When iCserver is running there are some keys that can be typed in into the terminal to do special stuff.  Below is a non-exhaustive list of characters and their meanings.  Will be updated accordingly when I get new useful tips and tricks from John (Wulff).

• q:
  Quits the running session in a safe way.  All open stuff is nicely closed, in my case all MCP's are reset to their default state and the iCserver is shut down.

• T:
  Shows a table overview of client names and registered senders/receivers.  An example is given below for my minimalistic test setup where I have a situation where I want to address a relay on another floor with a push button from one floor:
  
  

T

iCserver: Table of ClientNames and registered Senders and Receivers

QX522

ff_ic

gf_ic_o2

iCpiI2C

iCpiI2C-o2

%Equivalences = {

QX140  => [

    [ 1, { '' => QX140, } ],

    [ 4, { '' => IX14, } ],

],

}

EquivBase Channels

name base primCh secCh ch

IX14 QX140 1 4 4

QX140 QX140 1 1 1

ch  Sender          name            value       Recv[0] name[0] Recv[1] name[1] ...

1   ff_ic           QX140           0           iCpiI2C QX140 QX522 QX140

    4                                           gf_ic_o2 IX14

2   ff_ic           QX830           0           iCpiI2C QX830

3   iCpiI2C         IX831           0           ff_ic IX831

5   ff_ic           Cff_ic          2;ff_ic     <no receivers> [iClive]

6   <no sender>                                 ff_ic Dff_ic [iClive]

7   <no sender>                                 ff_ic IX20

8   iCpiI2C-o2      IX852           0           ff_ic IX852 gf_ic_o2 IX852 QX522IX852

9   iCpiI2C-o2      IX502           0           QX522 IX502

10  iCpiI2C-o2      IX503           64          gf_ic_o2 IX503 QX522 IX503

11  gf_ic_o2        QX522           1           iCpiI2C-o2 QX522 QX522 QX522

12  gf_ic_o2        QX853           0           iCpiI2C-o2 QX853 QX522 QX853

13  gf_ic_o2        Cgf_ic_o2       2;gf_ic_o2  <no receivers> [iClive]

14  <no sender>                                 gf_ic_o2 Dgf_ic_o2 [iClive]

15  <no sender>                                 gf_ic_o2 IX21

Equivalence is a mechanism where you use a kind of "bridge" to share a variable defined in one app over iCserver to another app.

To define an equivalence, the option -e has to be used in the setup files.

An example:

iCserver \

       -R ../../iCpiI2C -f -d300 \

    QX140,0xFF \

    QX830,0xFF \

  ~IX831,0xFF \

  -R ff_ic -e IX14=QX140 \

  -v ff_ic.vcd

In the above example, one app is "owning" the IEC output QX140.  Here, it is ff_ic.

Note that equivalence items must be defined on byte level, not bit level.

The value of QX140, however, must also be known in another app in my particular case to activate an LED in the pushbutton of a switch since that switch is also commanding the same device: a relay (see below).  

Using the "equivalence" mechanism, an internal IEC input byte IX is given the byte value of the QX IEC output byte and iCserver is "bridging" that value over the network to whom (in this case, another app) might be interested in it.

Note that bit 0 of QX140 is connected to a hardware pin in my system like so:

imm bit RBV1;

QX140.0 = RBV1;

The hardware pin itself is then controlling the state of a relay, here relay RBV1.

So, later on at the other app side the same bit of IX14 must be used!  In the example given above, bit 0 of IX14 is connected to bit 0 of QX140.

In the other app, the "bridge" variable IX14 can be used like so (here, one can and must use bit level now!):

imm bit gf$switch_led$kitchen_door$b;

gf$switch_led$kitchen_door$b = IX14.0;

QX853.1 = gf$switch_led$kitchen_door$b;

The above immediate bit variable is defined in an .ih file (immediateC header file) and is linked to the "bridge" variable bit IX14.0.

When there's more than one equivalence you can specify them using two options:

• -e IX14=QX140 -e IX15=QX150 

• -e IX14=QX140,IX15=QX150 

To build immediateC on a Raspberry Pi, the following steps have to be taken assuming Perl and so on are already installed correctly: see above sections:

• • ./configure (only if you modified the Makefile.in or you upgraded to the latest state on GitHub)

  • make distclean  (only if you want to do a clean build)

  • m -I (to temporarily switch a regular user to a root user: needed to change some permissions for installation purposes)

  • m -a 

Note that there's currently a problem during the build process with the command pod2man -u -n.  For an unknown reason the build mechanism doesn't recognise the -u option in my case (on John Wulff's Raspberry Pi it seems to be no issue...).
When looking into the Makefile.in, the pod2man -u -n is executed if the following condition is true:

 
    ifeq ($(TKGE803),true)

        @pod2man -u -n immcc -c 'iC Project Documentation' -r "icc.v $(REV)" $< > $(srcdir)/immcc.1

    else

        @pod2man -n immcc -c 'iC Project Documentation' -r "icc.v $(REV)" $< > $(srcdir)/immcc.1

    endif

        @gzip -f $(srcdir)/immcc.1

The variable TKGE803 gets its value at the beginning of the Makefile.in:

TKGE803 = $(shell perl -e 'use Tk; if ($$Tk::VERSION >= 803) { print "true"; }')

For a reason still unknown to me, TKGE803 gets the value true assigned.

Solution (for the time being): change "true" into "false" into the above statement so that TKGE803 gets the value "false" assigned instead of "true".
This way, the "ifeq" conditions further down the file will fail and the -u option will not be triggered anymore, resulting in a successful build.

Note that you have to run ./configure again after this change so that the final Makefile gets updated.

Generation

Example command:

iCmqtt -GT0 -F home/+ -I10 -Q10 ~/mystuff/openHAB/configurations/items/homecontrol.items

Output example:

pi@rpi3Bimmcff ~/mystuff/ff_poc$ (master) iCmqtt -GT0 -F home/+ -I10 -Q10 ~/mystuff/openHAB/configurations/items/homecontrol.items

home_ff_s_OHalias.ih generated with IX10 - IX18 and QX10 - QX14

home_ff_s_OHdeclare.ih generated

home_ff_s_OHtest.ic generated

 -I 19 -Q 15 -T 5 # input and output IEC addresses for next -G run

To generate the code, the most important parameters are:

• -G: generate the following files:

  • <prefix>_OHalias.ih 

  • <prefix>_OHdeclare.ih 

  • <prefix>_OHextern.ih 

where <prefix> is the prefix used in the items file of openHab.  Example: home/ff_s, home/ff_p, home/verdiep, gf_s, gf_p

• -F: filter to be used:

  • To grab everything in one go if you're using gf_s, gf_p, ff_s, ff_p is: [gf]f_[sp] as filter
    That should correspond with what has been defined in the .items file.
    
    In the above command, the filter is home/+.  This means every line starting with home/ and followed by whatever (can be ff_s/ff_p/gf_s/gf_p...) will be taken into account during generation.
    
    Example 1:
    
    Switch Sw_Door_CorrStudyroom_A "Studyroom - Switch_A" <switch> (FF_Corridor)
        {mqtt="
        >[immgeva:ff_s/Switch/Door_CorrStudyroom_A:command:ON:default],
        >[immgeva:ff_s/Switch/Door_CorrStudyroom_A:command:OFF:default],
        <[immgeva:ff_p/Switch/Door_CorrStudyroom_A:state:default]"
        }

This would need  ff_[sp] as filter.

Example 2:

Switch Sw_Door_CorrStudyroom_B "Studyroom - Switch_B" <switch> (FF_Corridor)
    {mqtt="
    >[immgeva:home/ff_s/Switch/Door_CorrStudyroom_B:command:ON:default],
    >[immgeva:home/ff_s/Switch/Door_CorrStudyroom_B:command:OFF:default],
    <[immgeva:home/ff_p/Switch/Door_CorrStudyroom_B:state:default]"
    }

This would need home/ff_[sp] as filter.

Example 3:

Switch Teleruptor_3_GF "Teleruptor 3" <office> (GF_Relays,GF_Teleruptors)
    {mqtt="
    >[immgeva:gf_s/IX21_4:command:ON:default],
    >[immgeva:gf_s/IX21_5:command:OFF:default],
    <[immgeva:gf_p/QX22_1:state:default]"
    }

This would need gf_[sp] as filter.

Others could be:

• • • home/[gf]f_[sp] in the following case:

Switch Sw_Door_CorrStudyroom_A "Studyroom - Switch_A" <switch> (FF_Corridor)
    {mqtt="
    >[immgeva:home/gf_s/Switch/Door_CorrStudyroom_A:command:ON:default],
    >[immgeva:home/gf_s/Switch/Door_CorrStudyroom_A:command:OFF:default],
    <[immgeva:home/gf_p/Switch/Door_CorrStudyroom_A:state:default]"
    }

Switch Sw_Door_CorrStudyroom_B "Studyroom - Switch_B" <switch> (FF_Corridor)
    {mqtt="
    >[immgeva:home/ff_s/Switch/Door_CorrStudyroom_B:command:ON:default],
    >[immgeva:home/ff_s/Switch/Door_CorrStudyroom_B:command:OFF:default],
    <[immgeva:home/ff_p/Switch/Door_CorrStudyroom_B:state:default]"
    }

• -T: Generate test code.  The number given should be smaller than  the -I or -Q option.  In this example it is 0, which means IX0... and QX0... will be generated and visible in the iCbox application.

Usage

iCmqtt -B -F home/+ -I10 -Q10 ~/mystuff/openHAB/configurations/items/homecontrol.items

Regenerate after change

Each time the test .ic file is changed, a make has to be run to generate the corresponding .c and executables.  So, the following command must be executed after a change:

iCmake home_ff_s_OHtest.ic 

Testing with openHab

To test the iCmqtt module with openHAB, do the following:

• Start the openHab application in debug mode!!!  Only then you will be able to access the openHAB server via a web browser.  I don't know (yet) why the non-debug version is not working fine.

• On a web page in a browser, go to the following URL: http://192.168.1.40:8080/openhab.app?sitemap=homecontrol
  You should see the layout defined in the homecontrol.items file, located in ~/openHAB/configuration/items directory

• Run the following command to start the immediateC environment:
  
  iCserver -R iCbox X0-X4,,400 -R iCmqtt -B -F home/+ -I10 -Q10 ~/mystuff/openHAB/configurations/items/homecontrol.items -R home_ff_s_OHtest
  
  This will start 2 iCbox components:

  • One to create the groups IX0-IX4 and QX0-QX4 where groups X0 to X4 are behaving like pushbuttons with a pressed state of 400ms.

  • One iCbox to monitor the openHAB input and outputs defined in the start command (here: IX10 and further + QX10 and further).

Next to this, the test application generated above will start and will communicate directly with the inputs and outputs of the iCbox application given in the start command (here I10 and further and Q10 and further).
When pressing a button on the test app iCbox dialogue, the connected QX output will react.   Since that output is triggered, it will send out an MQTT message that is picked up by openHAB and because of this the interface on the web page will follow the state of the relay.
See the function that is part of the generated test application

The test application has two inputs to the relay:

• One from the iCbox IX0-IX4

• One from the openHAB web page via MQTT

• The outputs of the relay go to both iCbox QX0-QX4 and via MQTT to the openHAB web page
  
  

I recently tried the newest Raspberry Pi OS called Trixie.  I quickly encountered issues when trying to set up the system for use with immediateC.

Not that immediateC gave issues.  Not at all!  But when I tried to run iClive I got the famous "Tk.pm not found" message.

Never mind, I thought, let's install it using CPAN.

No way, José!  Since Perl has been updated to version 5.40.1 the compilation failed.

Spending quite some time on it, but to no result.

I finally found a very convenient way of installing a matching Tk.pm for Trixie: sudo apt install perl-tk.  This is a precompiled version for Trixie that gives you no fuzz or  headaches to compile it yourself.

After installing this package iClive went fine!

Simpel as it can be!!!