Administrative

Projects

Active

Future

Finished

Reference

Abandoned

Project: HomeAutomation

Testing the full setup

Today I have tested prototypes of the whole automation infrastructure together: The control PC running the complete software stack, a switch input board with a "real" light switch, and an output controller with a "real" relay attached:

HA test setup with switch and output relay

The control PC and USB/Dual-CAN interface are stacked on the left side of the photo, the four PCBs arranged in the center are (clockwise, starting from top) a bus logic board (BLB) connected to the switch input controller, the relay output controller connected to another bus logic board.
The light switch (without front plate) is the silver-blue thing on the right hand side, the relay is laying on its side in front of the control PC housing. It is attached to the output controller through a 4-pin DIN plug, which will also be used to connect the switches to their respective controller board.

Note that the USB/Dual-CAN interface is still revision 1, which does not fit into the gray plastic box containing the control PC - but the rev2 board is already ordered and should arrive early in November.

Being on a week of vacation, I have spent nearly 11 hours on this today, mainly with debugging and fixing the new features I had built into the firmware for all the devices over the last weeks:

  • CAN devices IDs are now configurable through the UART interface using a simple command line interface
  • I2C identification of interface modules by the bus logic board works now
  • I used both CAN buses, and routing messages between the two did not seem to cause any issues
  • Retrieving the human-readable device description on the BLB from an array of strings (i.e. an array of an array of characters) from program memory on the microcontroller is fixed and works now

There is, however, some trouble with the control software: When I push the switch that is supposed to toggle the attached relay, the control program generates a CAN message of an invalid message type (1), where it should generate an "output digital" command. Furthermore, it always generates it for channel 0, even when it should be 5 or 1, respectively. The command code (3 for "toggle") is correct, however. What makes it trouble me even more is that everything worked fine when I generated the (identical) switch messages through my software emulator... But I am not going to look into that today.

The switch input firmware itself (scanning the inputs, deciding on whether it was a "normal" or "long" keypress, and generating CAN messages) surprisingly worked immediately on the first test run I did after programming it.

As a bonus and reminder for me, the debug log showing the current issue to solve:

>>> two different switches are supposed to trigger two different outputs, 
>>> but cause the same CAN datagram to be sent, with incorrect MTID and both
>>> addressing channel 0.
>>>
>>> the first dgram should trigger 01.02 at 134:5
>>> the second dgram should trigger 01.01 at 134:1

hashell:W=2:[0134]/> ha_iod[840]: Received CAN datagram on USB: "n !# /& !# !" !! !# !" !! !! !! !! "
ha_iod[840]: Parsed CAN datagram: "n !# /& !# !" !! !# !" !! !! !! !!"
ha_iod[840]: received CAN msg type "n"  addr "101" (bus 0, devid 101, mtid 5, devnr 101), length "2", data[0]="1", data[1]="0"
ha_iod[840]: usb_process_message: Sending to TCP: CR N 0101 05 2 001 000 002 001 000 000 000 000
ha_iod[840]: Connection closed on socket 8
ha_iod[840]: Reaping down TCP socket 127.0.0.1:64557
ha_iod[840]: Accepted connection from 127.0.0.1:64560
ha_iod[840]: Received TCP datagram on socket 8: "CD M 0134 01 2 000 003 000 000 000 000 000 000"
ha_iod[840]: Sending to USB/CAN: "m !) )' !# !! !$ !! !! !! !! !! !!"
ha_iod[840]: sent CAN msg type "m"  addr "2182" (bus 1, devid 6, mtid 1, devnr 0), length "2", data[0]="0", data[1]="3"
ha_iod[840]: usb_send_can(): Also sending to TCP: "CR N 2054 01 2 000 003 000 000 000 000 000 000"

>>> Received INDIGPULS from 0:101:1, Regular event
>>>   Device info: [<Element 'device' at 0x213187f0>]
hashell:W=2:[0134]/> ha_iod[840]: Received CAN datagram on USB: "n !# /& !# !! !! !# !" !! !! !! !! "
ha_iod[840]: Parsed CAN datagram: "n !# /& !# !! !! !# !" !! !! !! !!"
ha_iod[840]: received CAN msg type "n"  addr "101" (bus 0, devid 101, mtid 5, devnr 101), length "2", data[0]="0", data[1]="0"
ha_iod[840]: usb_process_message: Sending to TCP: CR N 0101 05 2 000 000 002 001 000 000 000 000
ha_iod[840]: Connection closed on socket 8
ha_iod[840]: Reaping down TCP socket 127.0.0.1:64560
ha_iod[840]: Accepted connection from 127.0.0.1:64584
ha_iod[840]: Received TCP datagram on socket 8: "CD M 0134 01 2 000 003 000 000 000 000 000 000"
ha_iod[840]: Sending to USB/CAN: "m !) )' !# !! !$ !! !! !! !! !! !!"
ha_iod[840]: sent CAN msg type "m"  addr "2182" (bus 1, devid 6, mtid 1, devnr 0), length "2", data[0]="0", data[1]="3"
ha_iod[840]: usb_send_can(): Also sending to TCP: "CR N 2054 01 2 000 003 000 000 000 000 000 000"

>>> Received INDIGPULS from 0:101:0, Regular event
>>>   Device info: [<Element 'device' at 0x213184d0>]


=======================

hashell:W=2:[0134]/> config S01.01.R
Device S01.01.R type "togglebutton" at CAN 101
    channel 1: "onoff"
  Short: "Test input 2"
  Long: "None"
  Location: "E-Lab"
  Group memberships:
    gr_Test_Switches: "All switches in test setup"
  Initiates actions:
     switch_toggled:   output_toggle to      01.02

hashell:W=2:[0134]/> config S01.01.L
Device S01.01.L type "togglebutton" at CAN 101
    channel 0: "onoff"
  Short: "Test input 1"
  Long: "None"
  Location: "E-Lab"
  Group memberships:
    gr_Test_Switches: "All switches in test setup"
  Initiates actions:
     switch_toggled:   output_toggle to      01.01

hashell:W=2:[0134]/> config
  DevID    | Adr | Ch |     Type     |              Description              
     01.01 | 134 |  1 |  relayoutput | E-Lab: Test output 1 (DIN plug) <onoff
     01.02 | 134 |  5 |  relayoutput | E-Lab: Test output 2 (hardwired) <onof
     01.03 | 134 |  3 |  relayoutput | E-Lab: Test output 3 <onoff>
     01.04 | 134 | 10 |       shades | E-Lab: Test shades device <updown>
     01.04 | 134 |  9 |       shades | E-Lab: Test shades device <onoff>
  S01.01.L | 101 |  0 | togglebutton | E-Lab: Test input 1 <onoff>
  S01.01.R | 101 |  1 | togglebutton | E-Lab: Test input 2 <onoff>
  S01.02.L | 101 |  2 | togglebutton | E-Lab: Test input 2 <onoff>
  S01.02.R | 101 |  3 | togglebutton | E-Lab: Test input 3 <onoff>

Reading through it now while checking this log entry, it seems strange that the devnr is 0 as well on the affected datagrams being sent. Perhaps something is wrong with the message ID calculation when addressing devices on bus 1.