AIO Release Notes

General

This firmware is based on the new hardware of the AIO. This Master processor of the AIO is from the Microchip DSPIC33E family and the firmware is written in C

The firmware updates happening in the Openmotics portal (Settings - Update) contain not only the firmware update of the Master, but also the firmware of other modules as well as the updates for the Beagle Bone Black. All these different firmware updates are assembled in a package which get's a general version number. This version number which you see in the portal is not the same as the Firmware Version of the Master. To check which firmware version is installed on the Master, in the Openmotics portal, go to Settings - Maintenance and open maintenance mode by pressing the Connect button. Type the instruction firmware version to read the Master Firmware version.

V1.0.143

Date: 24/06/2022

Resolved bugs

• When a sensor value becomes unavailable (via RS485: HVAC module or Sensor module), the sensor value in the Master remained at the last known good value. In this release, when a sensor becomes unavailable, it will be updated in the Master so correct indication in CLI will be seen as well as the appropriate events will be sent to the BB that the sensor is "NC".

V1.0.142

Date: 13/06/2022

Resolved bugs

• CLI instruction "dali input link write" now also supports 255 as Dali address so a programmed Dali link can be erased
• CLI instruction "dali output link write" now also supports 255 as Dali address so a programmed Dali link can be erased
• CLI instruction "dali sensor link write" now also supports 255 as Dali address so a programmed Dali link can be erased

Added functionality

• Memory model Page 0 Byte 86-89 has been added:
  • Byte 86-87: In these bytes, the timeout of state machine "Task Immediate queue" can be programmed
  • Byte 88-89: In these bytes, the timeout of state machine "Task Group queue" can be programmed
  • An "eeprom activate" is needed when the above bytes are modified

V1.0.141

Date: 06/06/2022

Resolved bugs

• When executing nested group actions, an additional BA (following the group) could be executed. This release solves this issue.
• When uCAN's are added, the address is checked before adding the uCAN to avoid uCAN's with address 255.255.255.
• To test Group Actions, the CLI instruction "basic action debug on" can be used to see what's been executed. However, the printing will slow down the execution so long group actions couldn't be executed fully. For this reason, the immediate queue timeout and the group queue timeout has been increased to 15 seconds.

V1.0.140

Date: 28/04/2022

Resolved bugs

• When the CLI instruction "input debug on" is used, a non-configured input is not being displayed when an input is pressed or released. This issue has been resolved in this release.
• For the Brain only: Input 0 was not working, input 2 triggered input 0 and 2. This bug is resolved in this release.

V1.0.139

Date: 14/04/2022

Resolved bugs

• When a lot of BA's are triggered at the same time, some BA's in the immediate queue were not correctly displayed (for example a press or release action that was not correctly displayed when "input debug on" & "basic action debug on" was activated). This release solves this issue.

Added functionality

• API Instruction "tR" Has been modified to support Heating & Cooling
• API Instruction "tW" Has been modified to support Heating & Cooling
• HVAC thermostat mode has been added that keeps the Heating/Cooling condition and communicate this the HVAC module over RS485. The changes in Thermostat mode are automatically stored in FRAM and are reloaded at startup
• CLI instruction "thermostat setpoint write" also supports the thermostat mode
• CLI instruction "thermostat setpoint read" also supports the thermostat mode
• CLI instruction "sensor list" will display the thermostat mode
• The thermostat mode is propagated to the HVAC module:
  • RS485 instruction has been changed, see https://wiki.openmotics.com/index.php/Master_RS485_Cummunication_Protocol#Request_Temp.2FHum.2FADC_of_HVAC_module_.28V2.29

Release Instructions

• When using an HVAC module, a firmware upgrade (V6.0.11 or higher) of the HVAC module is needed to cope with the above changes

V1.0.138

Date: 07/04/2022

Resolved bugs

• CAN bus delay could happen in installations with uCAN's (direct via Brain(+) and/or indirect via Can Control). This delay (sometimes a few seconds) was detected by the health checker that performed a reset to resolve the delay. This release resolves the delay problem.

V1.0.136

Date: 04/04/2022

Resolved bugs

• CAN stack improvements have been made to increase CAN stability

V1.0.135

Date: 28/03/2022

Resolved bugs

• During the CLI instruction "firmware version", some modules are not responding in the Master expected time. To give the modules more time to respond, the process has been made slightly slower in execution and more wait time is foreseen

Added functionality

• The CLI function "dev debug on" and "dev debug off" has been added to provide developers feedback
• The CLI function "pid debug on" and "pid debug off" has been implemented so the HVAC module live pid debug parameters can be displayed on the CLI console
  • This function works with HVAC firmware V6.0.10 (or higher)
  • When instruction "pid debug on" is used at a PID filter is active, following will be displayed:

17:51:15 084.075.215.000 pid:0 En:1(H) sensor:19.0(3) setpt:22.5 Err:7 P:49 I:0 D:0 Drive=49 Out=49(0)

Explanation:

• 17:51:15 -> Time
• 084.075.215.000 -> ID of the HVAC module (important when more then 1 HVAC module is connected)
• pid:0 -> PID 0 of the HVAC module is used
• En:1(H) -> Module is enabled (=1) and PÏD filter is in Heating(H) mode. Cooling(C) is also possible
• sensor:19:0(3) -> Sensor is measuring 19.0 degree celsius en Sensor (3) of this HVAC module is used for this PID filter
• sept:22.5 -> The thermostat setpoint is now set at 22.5 degree Celsius
• Err: 7 -> The calculated PID error is 7
• P:49 -> The calculated P result is 49
• I:0 -> The calculated I result is 0
• D:0 -> The calculated D result is 0
• Drive=49 -> The calculated PID drive (P+I+D) is 49
• Out=49(0) -> Analog output (0) will be driven with value 49 (0-255)

V1.0.134

Date: 23/03/2022

Added functionality

• Preparation for implementing the PID debug functionality of the HVAC module on the master (not working yet):
  • Implementation of added RS485 instruction

Important Note

• This version cannot be used as production version

V1.0.133

Date: 22/03/2022

Resolved bugs

• When an automatic search is ongoing and a Bus error is detected, the search can get aborted. In this release, when a bus error is detected during an automatic search, the search is stopped and restarted
• When output modules are automatically added using the automatic discover function, some outputs were configured as shutter which is resolved in this release

Added functionality

• Preparation for implementing the PID debug functionality of the HVAC module on the master (not working yet):
  • Instruction "pid debug on" has been added
  • Instruction "pid debug off" has been added

V1.0.132

Date: 14/03/2022

Resolved bugs

• This is a dummy release for test purposes only

V1.0.131

Date: 14/03/2022

Resolved bugs

• The Brain(+) has 2 I2C buses. These buses are controlled by dependent state machines. When a main state machine using the I2C dependent state machine got blocked and has to be reset, the I2C dependent state machine could remain in a state where the bus got blocked. To avoid this situation, this release contains a change where the I2C depend state machines are converted to I2C main state machines in other words, I2C is not dependent anymore of the main state machine.

Added functionality

• During startup, the search of RS485 modules will not automatically be started anymore. The BB will use the necessary BA's to start the search when needed and appropriate and when the BB is ready (all reads etc are done) so the Master has the necessary processor time to execute this search. The CLI instruction "module discover search" can also be used to start the search process and can be stopped by using the instruction "module discover stop".

V1.0.130

Date: 07/03/2022

Resolved bugs

• V1.0.129 had some state machine instability that has been resolved in this release

Added functionality

• API Instruction "tR" has been added: This instruction will read the thermostat value and all linked sensor values. See API Reference Guide AIO.
• API Instruction "tW" has been added: This instruction will write the thermostat value. See API Reference Guide AIO.
• API Instruction "mR" has been added: This instruction will read the Eeprom Memory of a RS485 slave module. See API Reference Guide AIO.
• API Instruction "mW" has been added: This instruction will write the Eeprom Memory of a RS485 slave module. See API Reference Guide AIO.
• Error 25 has been added. See Error List AIO.

V1.0.129

Date: 25/02/2022

Resolved bugs

• The Reset byte (Eeprom Page 0 Byte 85) was read from the wrong location in Eeprom. This is resolved in this release.
• On the Brain, input 1 and input 3 are switched in order. In this release, input 1 and 3 are switched. For customers using these inputs, a reconfiguration of these inputs will be needed!
• On the Brain(+), when using the internal 0-10V outputs and the 1 button dimming was used, errors occurred in the output state machine which could be seen in the "Fram logging".
• When state machines are taking longer then expected, state machines could be killed even in the middle of an I2C session resulting in a I2C corrupt bus. This release will avoid state machines to be killed when an active I2C session is ongoing.
• The FRAM buffer has been increased (from 50 to 250) to avoid buffer overflow resulting in multiple state machines taking longer than expected (until new space available in the buffer).

Added functionality

• Endless loop detection has been added in this release:
  • Endless loop is a detection mechanism to detect when a group action will execute itself, or when for example a group action will execute a group which has the output group follow function enabled that executes again the same group action which can result in endless loops making the Master unresponsive.
  • When the Endless loop detection is enabled, group actions with the same action number can only be executed once in 1 execution run. An execution run stops when the active BA queue size returns to 0.
  • When nested groups are used, every new group action will check all parent groups to see if no double exist (and thus a loop is created).
  • In Eeprom Memory Model, Page 0 Byte 84 has been added to enable/disable the Endless loop detection
  • Event 19 has been added: When an endless loop is detected, this event will be thrown
• CLI instruction "input link write" only allows input in range with outputs in range (max number that can be used is the MAX OUTPUTS = 480). To unconfigure an input from an output, it wasn't possible. From this release, it's possible. Example (first link input 32 with output 8)

input link write 32 8
OK

input link read 32
Input 32 is linked to Output 14
OK

If you want to unconfigure input 32:

input link write 32 65535
OK

input link read 32
Input 32 has no Output nor any action(s) linked
OK

Important Note

• This version cannot be used as production version

V1.0.128

Date: 14/02/2022

Resolved bugs

• The automatic search mechanism for RS485 modules was failing when more then 1 module of the same type needs to be added, only the last module of that type was added. This release fixes this issue and make sure that all RS485 modules are added.

Added functionality

• This release supports reading Serial number and Testing data by the Test System

V1.0.127

Date: 03/02/2022

Resolved bugs

• Wrong detection of module type (Brain or Brain(+)) resulting, for the Brain+, that leds and buttons didn't function correctly anymore
• In the startup sequence of the leds (10 times flashing), Open Collector output 5-8 also followed the flash sequence. This is not the case anymore in this release.
• For the Brain+, during a reset, the 0-10V outputs are being kept at 0V until the full startup is done and Eeprom activate is executed. This could take between 5 and 10 seconds before the 0-10V output have again the required output. This release will set the correct 0-10V output within +/-1 second after reset.
• API Instruction "PC" generated an error when pulse counter series had a value higher then 1

V1.0.126

Date: 31/01/2022

Resolved bugs

• When a new CAN bus is created and the Micro CAN's are not initialised yet, the traffic is very limited so the Micro CAN detects no traffic and will indicate the CAN bus status as not OK. In this release, the Master will sent keep alive messages every 10 seconds so the status led on the Micro CAN is correct all the time.
• The reliability of setting front panel leds is improved. In this release, also no events will be sent anymore when the led status have been changed to lower the number of messages sent from the Master to the BB.
• When the I2C power is applied during startup, the Open Collector outputs are immediately driven. In this release, the I2C chips are initialised faster to minimise the time the Open Collector outputs are driven during startup.
• The API "FM" instruction had the wrong ID format making the boot loader of Micro CAN's over CAN Control fail. This is resolved in this release.

Added functionality

• Pulse Counter implementation is changed:
  • Eeprom Memory Model Input page - First page Byte 120-127: Link an input to a Pulse Counter
  • Maximum of 32 Pulse Counters is configured now
  • Only Pulse Counters of External Input Modules or the 5 internal inputs are accepted as Pulse Counter
  • Input Module Firmware F6.0.27 or higher is required
  • Pulse Counters are automatically checked by the Master every 30 seconds
  • When a change is detected, an Event will be sent
  • API Event 3 has been added: When a Pulse Counter has been updated, this event will be sent
  • API Instruction "PC" has been changed

V1.0.124

Date: 18/01/2022

Resolved bugs

• API Instruction "FM" used during the full bootload process of the Micro CAN was not always using the correct destination address in case of boot loading of a Micro CAN over the CAN Control module. This release solves this issue.

Added functionality

• API Instruction "FM" also allows now to sent CAN broadcast messages

V1.0.121

Date: 10/01/2022

Resolved bugs

• When configuring a duo output as shutter and both outputs are ON (using BA10 104), both outputs should be switched OFF at the time of configuration.

Added functionality

• CLI instruction "thermostat setpoint read" has been added: This instruction will read the Thermostat Temperature Setpoint
• CLI instruction "thermostat setpoint write" has been added: This instruction will write the Thermostat Temperature Setpoint
• CLI instructions with "," are also accepted. Example:

thermostat setpoint write 5 60,5

or

thermostat setpoint write 5 60.5

will both work

• Modbus functionality for Micro CAN's have been disabled in Master code since not in use
• Thermostat setpoints are stored in FRAM so a system restart will immediately load the last setpoint and continue operations:
  • All set points are loaded from FRAM during system start
  • New set points are automatically written in FRAM as well

V1.0.120

Date: 31/12/2021

Added functionality

• Remote eeprom reading/writing of RS485 slaves
  • With CLI instruction "eeprom read" you can read the processor built-in eeprom of a RS485 slave
  • With CLI instruction "eeprom write" you can write the processor built-in eeprom of a RS485 slave
  • Some eeprom addresses, that are in a protected area (with serial number for example), are write protected if these bytes have already been written
  • CLI instruction "eeprom read" and "eeprom write" have been extended to be able to cope with the above functionality
  • RS485 instruction "Read Slave Eeprom" have been added
  • RS485 instruction "Write Slave Eeprom" have been added

Example: Read input module with address 73.20.51.10 eeprom location 1

eeprom read 73 20 51 10 1
73 (1)
OK

V1.0.119

Date: 24/12/2021

Resolved bugs

• Some modules (with older firmware like input F6.0.17 & F6.0.23) are not able to be discovered. This firmware helps to resolve this issue.
  • Eeprom Memory model Page 0 Byte 11 has been modified: BIT2 has been added to be able to disable full handshake of the discovery of new modules.

Release instructions

Guideline how to add a module that can't be discovered

• Step1: Go to maintenance mode
• Step 2: Stop any discovery ongoing

module discover stop

• Step3: Change the automatic discovery setting in eeprom:

eeprom write 0 11 2

• Step 4: Activate this setting:

eeprom activate

• Step 5: Start the discovery mode

module discover start

• Step 6: Push the init button, you will get the below message (it's normal you get 2 times the same message, the ID will of course not be the same as below)

New Input module (I) found: 073.157.108.015
New Input module (I) found: 073.157.108.015

• Step 7: Add all the modules that needs to be added
• Step 8: Stop discovery mode

module discover stop

• Step 9: Set the discovery setting in eeprom to standard again

eeprom write 0 11 255

• Step 10: Activate this setting:

eeprom activate

Notes:

• When an input module with F6.0.23 is used, the above procedure will work correctly
• When an input module with F6.0.17 is used, it might be that the above procedure will not work when the automatic search has been performed (the module doesn't sent init messages when pushing init button). This can be solved by doing the following:
  • After Step4, perform a power reset of the full installation
  • After the Power reset, continue at Step5

V1.0.118

Date: 20/12/2021

Resolved bugs

• When configuring a duo output as shutter and both outputs are ON (using BA10 100), both outputs should be switched OFF at the time of configuration.
• When using "can debug on", situation could occur that a storm of messages appears on the screen. In this release, this is filtered.

Added functionality

• CLI instruction "can config list" will now also check if a non responding uCAN is in boot loader and will indicate this (FIR-164):

can ping list
-Nr-Bus-ID2.ID1.ID0-Hw_Rev----Serial----Inp.link0-Inp.link1-Inp.link2-Inp.link3-Inp.link4-Inp.link5-Tem.link0-Tem.link1-Type-Firmware-Boot-ID_NE-CanP1-CanP2-CanP3-CanP4-CanP5-Stat--Min-MAX-delay--Volt--
 00 100 038.024.080  000  000000000000  013(005)  012(004)  011(003)  010(002)  009(001)  008(000)  000(000)  255(255)  004  F06.00.26 255  069   255   255   255   255   255   247  000 255 001ms 10.66V
 01 100 201.233.217  DEVICE IN BOOTLOADER!!!
 02 100 198.140.192  000  000000000000  019(011)  018(010)  017(009)  255(255)  255(255)  255(255)  255(255)  255(255)  000  F06.00.25 255  069   255   255   255   255   255   247  000 255 001ms 10.90V
OK

• Eeprom logging has been setup to keep module management (FIR-164):
  • RS485 modules that have been added (manually or automatically) will be stored in Eeprom as an Event
  • uCAN modules that have been added will be stored in Eeprom as an Event
  • "can config delete" instructions will be stored in Eeprom as an Event
  • Factory reset instructions and action will be stored in Eeprom as well
  • See https://wiki.openmotics.com/index.php/AIO_API_Event_Codes
  • Eeprom model: Page 0 Byte 83-84 has been moved to the eeprom protected area Page 0 Byte 128-129 to avoid eeprom logging erasing while doing a factory reset
  • Fram model: Page 0 Byte 83-84 has been moved to the eeprom protected area Page 0 Byte 128-129 to avoid Fram logging erasing while doing a factory reset
  • Example:

eeprom logging
0000(P510/B240): 19/12/21 18:02:28 EV 030 000 000 064 087 111 000 077
0001(P510/B224): 19/12/21 18:00:16 EV 200 000 000 008 000 001 000 118
0002(P510/B208): 19/12/21 17:58:47 EV 030 000 000 064 087 111 000 077
0003(P510/B192): 19/12/21 17:56:02 EV 200 000 000 008 000 001 000 118
0004(P510/B176): 19/12/21 17:54:26 EV 030 000 000 064 087 111 000 077
0005(P510/B160): 19/12/21 17:50:39 EV 200 000 000 008 000 001 000 118
0006(P510/B144): 19/12/21 09:43:53 EV 030 001 003 098 000 000 003 077
0007(P510/B128): 19/12/21 09:43:47 EV 030 000 001 150 163 190 000 077
0008(P510/B112): 19/12/21 09:41:19 EV 030 001 000 115 000 000 000 077
0009(P510/B096): 19/12/21 09:41:18 EV 030 001 002 098 000 000 002 077
0010(P510/B080): 19/12/21 09:41:16 EV 030 000 000 042 193 007 000 077
0011(P510/B064): 19/12/21 08:25:17 EV 030 001 001 079 190 129 000 065
0012(P510/B048): 19/12/21 08:25:17 EV 030 001 000 067 128 047 000 065
0013(P510/B032): 19/12/21 08:25:16 EV 030 001 001 073 206 182 000 065
0014(P510/B016): 19/12/21 08:19:45 EV 200 000 000 008 000 001 000 118
0015(P510/B000): 18/12/21 19:42:44 EV 030 001 001 079 250 007 000 065
0016(P509/B240): 18/12/21 19:42:44 EV 030 001 000 067 160 047 000 065
0017(P509/B224): 18/12/21 19:42:27 EV 200 000 000 008 000 001 000 118
0018(P509/B208): 18/12/21 19:29:22 EV 030 001 001 079 125 003 000 065
0019(P509/B192): 18/12/21 19:29:22 EV 030 001 000 067 032 047 000 065
0020(P509/B176): 18/12/21 19:28:57 EV 200 000 000 008 000 001 000 118
0021(P509/B160): 18/12/21 19:01:11 EV 030 001 001 079 190 129 000 077
0022(P509/B144): 18/12/21 18:59:19 EV 030 001 000 067 064 223 000 065
0023(P509/B128): 18/12/21 18:59:18 EV 030 001 001 079 190 129 000 065
0024(P509/B112): 18/12/21 18:53:37 EV 200 000 000 008 000 001 000 118
0025(P509/B096): 18/12/21 18:50:04 EV 200 000 000 008 000 001 000 118
0026(P509/B080): 18/12/21 08:49:15 EV 200 000 000 008 000 001 000 118
0027(P509/B064): 18/12/21 08:45:43 EV 200 000 000 008 000 001 000 118
0028(P509/B048): 18/12/21 08:30:10 EV 200 000 000 008 000 001 000 118
0029(P509/B032): 18/12/21 08:26:39 EV 200 000 000 008 000 001 000 118
0030(P509/B016): 18/12/21 08:23:24 EV 030 001 002 079 125 003 000 065
0031(P509/B000): 18/12/21 08:23:24 EV 030 001 001 067 160 047 000 065
OK

• Action Type 254 4 has been added: Factory reset of slave modules only
• CLI instruction "can control number modules read" has been added
• CLI instruction "can control number modules write" has been added
• This release together with uCAN F6.0.26 supports the automatical adding of existing uCAN's with an existing ID (FIR-158)

V1.0.117

Date: 03/12/2021

Resolved bugs

• API Instruction PC had the CRC of the Pulsecounter values implemented as little endian and it should be big endian. This has been corrected in this release.

V1.0.115

Date: 29/11/2021

Added functionality

• Factory reset has been added in this release
• A Factory reset will Execute all necessary steps to perform a full wipe:
  • Send the necessary instructions on the CAN bus (direct connected CAN and CAN busses connected over a CAN Control) to delete the CAN config of the uCAN's
  • Erase the config of the connected RS485 slave modules (all config included the ID of the modules)
  • Erase the EEPROM of the Master (except the protected areas like serial number, production data, uptime, logging information etc)
  • Erase the FRAM of the Master (except the protected areas like logging)
  • Log the erase steps in FRAM
  • Send Events to the BB of the different factory reset steps
• Following has been added:
  • BA254 2 has been added: Prepare factory reset
  • BA254 3 has been added: Execute factory reset
  • EV200 0 has been added: For every phase of the factory reset, an event is sent

Notes:

• A factory reset is irreversible, all configuration will be lost
• FRAM logging, EEPROM logging and Factory settings will not be erased
• When a factory Reset is performed, errors might appear on the CLI console (input error, output error etc), this is normal and can be ignored
• Factory reset is available in following firmwares:
  • Master: V1.0.115 or higher
  • Input Module: V6.0.25 or higher
  • Output Module: V6.0.18 or higher
  • Temperature Module: V6.0.16 or higher
  • Dim Control Module: V6.0.19 or higher
  • CAN Control Module: V6.0.43 or higher
• See https://wiki.openmotics.com/index.php/AIO_Tips_%26_tricks_during_installation_and_troubleshooting#Factory_Reset

Unresolved bugs

• After a factory reset, it might happen that the uCAN's can't be added
  • Workaround: perform a reset in the CLI console

reset

V1.0.114

Date: 23/11/2021

Resolved bugs

• Stabilisation of the DALI functionality via CAN Control:
  • Support of DALI output
  • Support of DALI motion sensors
  • Support of DALI sensors (temp & lux)

V1.0.113

Date: 15/11/2021

Added functionality

• To support DALI over CAN Control, following functionality has been added:
  • BA21 20, BA21 21 & BA21 22 have been moved to BA21 40, BA21 41 & BA21 42
• CLI instruction "?" has been removed since it takes a lot of flash memory
• CLI instruction "dali debug on" and "Dali debug off" has been added:
  • When this debug function is on, information that is sent and received on the data bus is displayed on the CLI console
• CLI instruction "dali output on" and "dali output off" has been added:
  • These instructions allow to sent Dali message on the bus without any configuration. This helps testing the Dali Bus before starting the configuration.
• CLI instruction "add virtual input module" has been added
• CLI instruction "add virtual dimmer module" has been added
• CLI instruction "add virtual output module" has been added
• CLI instruction "add virtual sensor module" has been added
• CLI instruction "can debug on" has been added to debug CAN messages coming from the internal bus or can messages from the CAN control
• CLI instruction "can debug off" has been added
• CLI instruction "can message" has been added to allow CAN messages to be sent via CLI

Known issues

• For DALI, this version is a beta version:
  • DALI functionality in this version is not yet stable and requires further testing and bug fixing
  • This version CANNOT be used in production

V1.0.112

Date: 22/09/2021

Resolved bugs

• The first CD response was using CID 0 instead of the CID being sent by the BB. This has been resolved in this release.
• Output type (see eeprom P1-80 B31-38) was not automatically adapted for Roller/Shutter outputs. In this release, when an Roller/shutter configuration is detected, the output type is automatically adapted in RAM (eeprom value remains unchanged).

V1.0.111

Date: 21/09/2021

Resolved bugs

• API call CD was not always responding and was generating an UART Error. This has been resolved in this release.
• API call ST type 2 had a wrong message length

V1.0.110

Date: 20/09/2021

Resolved bugs

• The brightness Event was sent on a regular basis even when brightness sensor was not connected. This release solves this issue.
• When BA20 71 (switch led ON when nr_of_lights_on>x) is used, the led will switch ON but not OFF. This is resolved.
• BA20 70 has the same bug
• BA20 72 had the same bug
• BA20 73 has the same bug

Added functionality

• RS485 communication protocol has been modified to support the Heat Pump module.
• The module type "H" represents the Heatpump module
• Memory model has changed to prepare the implementation of DALI on the CAN Control:
  • See Page 1-80 Byte 71..: DALI: Link Output Nr with Dali Nr
  • See First Page Byte 15..: DALI: Link Input Nr with Dali Nr
  • See Page 239-254 Byte 72: DALI: Link sensor Nr with Dali Nr
• API CD message has been changed: A response is sent by the master with the number of uCAN's before the individual messages are being sent.
• API ST (type=2) message has been changed: Message will contain the number of input, output and sensor modules.
• Event 23 has been added: When API CD message is used and a uCAN is not responding, Event 23 will be sent.
• Event 24 has been added: When API ST (type 2) message is used and the RS485 module is not responding, Event 24 will be sent.

Release instructions

• For installations that have Dali configurations active before this firmware upgrade, please follow this Dali Eeprom Memory Model change procedure

V1.0.109

Date: 02/09/2021

Added functionality

• When API Instruction "FM" is used, the Healthcheckers (except i2c health checker) master reset functionality will be disabled. When an Eeprom activate is executed, the health checker will be enabled again and the health check eeprom bytes will be used to verify if the health checker is active or not.
• Event 254 has been modified: Reset_mode has been added.
• CAN instruction has been added for the test system to read the full serial number without writing
• In the CLI instruction "can ping list", the Hw revision, serial number and production date has been added
• CLI instruction "eeprom read" and "eeprom write" is extended to also read and write the eeprom of the uCAN slave modules. This function requires uCAN Firmware Version 6.0.21 or higher
• Normally, an internal eeprom read has 2 or 3 arguments, an eeprom read of a uCAN has 4 arguments:

eeprom read Id2 ID1 ID0 Eeprom_Loc

Example:

el
--- Total Uptime: 000216 Hours, Last Startup: 08:02:09 02/09/21   ---
--- Module Type: BRAIN, RS485 mode: 0, Board: 27'C  --.--V --.--A ---
--- PWR RS485/CAN: 1/1, CANTERM: 1, BB Debug: 255, Fw: 1.0.109       ---
-------Output------------ID---------Err-------Status--------Pwr---
 00 (l I 000->007) 108.000.000.000 00000   GOOD       (000)  1
-------Input-------------ID---------Err-------Status--------Pwr---
 00 (i I 000->007) 105.000.000.000 00000   GOOD       (000)  1
 01 (b C 008->015) 098.000.000.001 00000   GOOD       (000)  1
 02 (b C 016->023) 098.000.000.002 00000   GOOD       (000)  1
 03 (b C 024->031) 098.000.000.003 00000   GOOD       (000)  1
 04 (b C 032->039) 098.000.000.004 00000   GOOD       (000)  1
-------Sensor------------ID---------Err-------Status--------Pwr---
 00 (s C 000->007) 115.000.000.000 00000   GOOD       (000)  1
-------Micro CAN---------ID---------Err-------Status--------Pwr---
 00 (m C 000->000) 100.069.253.220 00001   GOOD       (000)  1
 01 (m C 001->001) 100.052.078.228 00000   GOOD       (000)  1
 02 (m C 002->002) 100.135.225.126 00000   GOOD       (000)  1
 03 (m C 003->003) 100.091.059.166 00000   GOOD       (000)  1
OK
eeprom read 91 59 166 30
15
OK

• An eeprom write of a uCAN has 5 arguments:

eeprom write Id2 ID1 ID0 Eeprom_Loc Data_byte

Example:

eeprom write 91 59 166 30 20
20
OK
eeprom read 91 59 166 30
20

OK

V1.0.108

Date: 17/08/2021

Resolved bugs

• For the Brain+, the internal built-in Dim Control functionality was still working at a resolution of 0-63 instead of 0-255. This has been resolved in this release.
• BA20 9 till BA20 19 had a wrong translation to CAN bus message

Added functionality

• Improved and simplified CAN Bus health checker

V1.0.107

Date: 31/07/2021

Resolved bugs

• Dimming up & down by using a button didn't dim over the full range.
• The eeprom programmed minimum dim value was incorrectly used and always had value 63.
• After a reset, the dim direction was not always set correctly resulting in a second press needed to start dimming.

V1.0.106

Date: 27/07/2021

Resolved bugs

• During Init mode, the Health checker was still running but uCAN's behind a CAN Control are not reachable as expected. This could trigger the health checker reset and this is resolved in this release.
• Event 247 (PCB temperature) reported his value in the wrong field compared to documentation.

Added functionality

• Event 245 has been added: During init mode, when a existing or double slave module has been found, this event will be sent.
• Event 246 has been added: When an Automatic module search is started, ended or not started (Automatic Discovery is OFF), an event will be sent.
• Event 248 has been modified and now indicates the difference between a regular Eeprom activate and an Eeprom activate just after startup (or reset)

V1.0.105

Date: 26/07/2021

Resolved bugs

• CLI instructions "input number modules write 0", "output number modules write 0" and "sensor number modules write 0" were accepted by the master but not executed. This has been resolved in this release.
• Instructions (BA20 10, BA20 11 etc) to reprogram an input could generate a factory reset of all connected uCAN's. This has been resolved in this release.
• Improved uCAN health checking
• CLI instruction "can ping list" was having trouble finding uCAN's behind a CAN Control, this has been solved in this release as well.

Added functionality

• CAN speed change for CAN Control has been added:
  • Memory model Page0 Byte26-29 has been added (CAN settings for CAN Control)
  • During Eeprom activate, CRC of CAN Control settings are calculated before activating
  • RS485 instruction has been modified to include the CAN Control CAN settings, see: https://wiki.openmotics.com/index.php/Can_Control_RS485_Communication_Protocol#Nothing_to_report_from_Master.2C_request_if_something_in_the_Queue_of_Can_Control_Module
• CAN speed 250kbps has been added. This speed can be used by applying following instruction:

can speed write 250

V1.0.104

Date: 19/07/2021

Resolved bugs

• First time setup of a CAN bus gave problems with CAN bus speed (uCAN's were not able to communicate). This release solves this problem.

Added functionality

• Master Firmware version V1.0.104 or higher has an improved search mechanism for slave modules: When a new slave module is found during the automatic search, first the Master will check if the Slave module is responding, when positive the Master will request the slave module to program its slave address, after this the slave module will respond to the master that the slave address is programmed and only then the module is added in the Master list. The automatic search will only work with following slave firmware versions (below is the newer version):
  • Output V6.0.15 or higher
  • Dim Control V6.0.16 or higher
  • Input V6.0.23 or higher
  • Temp V6.0.13 or higher
  • Can Control V6.0.36 or higher
• When CLI instruction "can config delete" is used, a broadcast message will be sent to all the uCAN slaves (with Firmware version 6.0.17 or higher) to factory reset every connected uCAN.

Release instructions

Factory Reset of a full installation can be done with following guideline

• Use following instruction to delete the CAN config (please make sure you have fw version 6.0.17 or higher for the uCAN's):

can config delete

• Use following instruction to delete the Master eeprom:

eeprom erase 0 511 28883

• On the slave modules, push the init button during power startup until the status led flashes 4 times
• Use the CLI instruction

reset

Manual Init of slave modules with an older firmware version

When this firmware release is used with older versions of slave modules, adding modules may not work. Use following work around to add these modules:

• Change the search functionality setting

eeprom write 0 11 0

• Perform Eeprom activate to copy Eeprom settings into RAM:

eeprom activate

• Use now the manual procedure to add modules:

module discover start

• press the init button on the modules to be added. Once done, leave the discover mode:

module discover stop

• Automatic search can be activated again:

eeprom write 0 11 255

Manual Init of slave modules with an newer firmware version

When the newer firmware version is used (which should be always the case), use below instruction to change to manual search:

• First set the correct Eeprom value:

eeprom write 0 11 2

• Activate the Eeprom value

eeprom activate

• Start the manual discovery process

module discover start

• Press the init button of the modules that you want to add, then stop the discovery process

module discover stop

• You can enable the automatic search again:

eeprom write 0 11 255
eeprom activate

V1.0.103

Date: 13/07/2021

Resolved bugs

• Some error messages in CLI during initialisation were not displayed fully. This has been resolved in this release.
• When an automatic search was ongoing and this was stopped by using "module discover stop", "module discover start" would make the search continue which is not what to be expected
• The automatic search and the adding of modules have been improved
• In some cases, double Module ID's could be created during initialisation and this has been resolved in this release

Added functionality

• Event 254 1 (PCB temperature) has been moved to Event 247 0
• Event 254 x has the firmware version added in the data payload
• API Instruction "AM" has been added
• API Instruction "AM" will be send when a new module (normal or virtual) has been added
• After each startup, the Master will perform an automatic search for new modules. When this search take more time then +/- 10 minutes, the health checker will automatically stop the search and bring the bus in live mode.

V1.0.102

Date: 28/06/2021

Resolved bugs

• Automatic search function was generating errors during search and sometimes failing to find all modules. This issue has been solved in this release. Please note that the Automatic search can take up to 5 minutes to find all modules.

Added functionality

• Automatic search function has been added for Output modules that are being placed in Roller/Shutter mode before initialization
• Automatic search function has been added for Dim Control modules

V1.0.101

Date: 20/06/2021

Resolved bugs

• Recovery of failed I2C1 Bus has been improved
• Improved CAN led functionality: When many leds were being set, not all leds did respond correctly
• CAN parameters correction for correct speed
• Health checker has been improved:
  • Ping messages only allows timeout of 20ms
  • When CAN problems are happening, first try to reset the CAN stack before resetting the processor
  • The reset of the CAN stack will also be logged in FRAM
• Improved CAN bus stability: Too fast sending messages on the CAN bus could bring uCAN leds in an wrong state.
• Output group follow actions did not work for "output all off" instructions and BA's
• After a reset, the leds of the inputs are set correctly

Added functionality

• CLI instruction "can speed write" can now be used without parameter
  • This allows that customer values being written in Eeprom can be used to distribute custom CAN speeds

V1.0.98

Date: 13/06/2021

Resolved bugs

• "DALI on" message contained an error due to dimmer value and didn't switch on the concerning light.
• "DALI group" was not switching the appropriate lights
• Some programmed shutters (with outputs >=32) didn't appear and didn't work as expected.
• On the Frontpanel, when input was selected, input 6-8 lights up but those inputs are not connected

V1.0.89

Date: 08/06/2021

Resolved bugs

• When a uCAN that was initialised previously was resending a sensor message (without an input that was initialised on this uCAN) generating errors on Master level. This is resolved in this release.
• uCAN's sometimes gave communication errors (seen in the "error list")
• During the I2C power reset, the Eeprom and FRAM were still powered through the WP pin so hardware reset was not effective
• CAN parameters have been modified to improve CAN network stability. This release must be done together with Can Control V6.0.32 and uCAN V6.0.14.

Added functionality

• Event and Error logging has been extended:
  • Logging is also possible in Eeprom (previously already available in FRAM)
  • Startup info is also logged in Eeprom
  • I2C2 (I2C Bus of FRAM) problems are logged in Eeprom
  • See Eeprom memory model Page 506-511
  • See Eeprom memory model Page 0 Byte83-84
  • CLI instruction "logging list" has been removed
  • CLI instruction "eeprom logging" has been added
  • CLI instruction "Fram logging" has been added
• CAN Health Checker:
  • Bus off state is detected, will log the problem and reset the Master
• CAN Speed selection: In this release (together with uCAN V6.0.14 or higher), you can change the speed of the CAN bus.
  • CLI instruction "can speed read" has been added
  • CLI instruction "can speed write" has been added
  • Memory model Page 0 Byte 14-26 have been added
  • CLI instruction "can ping list" has been modified to display the CAN parameters
  • In this release, the speed of the CAN bus can be changed between 20, 50, 125 and 250kbps (effective after reset)
  • See https://wiki.openmotics.com/index.php/AIO_Tips_%26_tricks_during_installation_and_troubleshooting#Changing_CAN_bus_speed
  • API Instruction "CD" has been modified to include the CAN parameters

V1.0.88

Date: 24/05/2021

Resolved bugs

• I2C power reset is improved (SDA and SCL line are brought down during power reset)
• Serial number error: CLI instruction "firmware version" didn't display the programmed serial number
• State machine "Update Time/Date" was generating errors from time to time. This was linked to a bug in the Non blocking delay used in this state machine. This also has been solved in this release

Added functionality

• Event 254 3 (Health Checker Info) has been moved to Event 248 3
• Event 248 2 (I2C Power reset) has been added
• Health Checker
  • CAN health checker has been added
  • CAN problems are logged in FRAM
  • CAN recovery is logged in FRAM
  • When CAN can't be recovered, a Master Reset is executed
  • Before the Master reset is executed, an event is sent and the logged in FRAM

V1.0.87

Date: 18/5/2021

Resolved bugs

• When a BA loop generates a full BA queue, the I2C bus could get blocked. This release solves this issue.
• When a uCAN was generating errors (for example not connected) and not responding, the error list was indicating after a while that the uCAN was "DEGRADED" or 'OFFLINE". When reconnecting the sensor, the state was not been changed to "GOOD".
• The time to do a full erase of EEPROM or FRAM was not long enough resulting in a partial erase. This is resolved in this release

Added functionality

• Serial number:
  • CLI instruction "Firmware version" has been modified: Serial number has been added
  • RS485 instruction "FL" has been added
  • Communication has been adapted so not only firmware version but also serial number will be requested from the slave modules
• Network Health Checker:
• I2C health checker:
  • First version written but not yet active
  • Both I2C busses are checked every 10 seconds
  • I2C Bus 1 contains the EEPROMS
  • I2C Bus 2 contains the RTC, FRAM, Front panel leds, DA converter (Brain+ only) etc
  • Bus 1 is tested by reading the Eeprom
    • When the Eeprom is not responding, the state machine gets a reset
    • When the Eeprom is still not responding, the master will be reset including a power reset of all i2c IC's
  • Bus 2 is tested by reading the RTC time
    • When the time is not increasing, first reset the state machine
    • When the time is still not increasing, reset the master including a power reset of all i2c IC's
  • Before a Reset is performed, an API EV message is sent
  • Reset information will also be logged in FRAM (only when resetting due to I2C Bus 1)
  • EV 254 2 has been modified
• FRAM logging:
  • FRAM Page0/Byte 83-84 have been added
  • FRAM Page 53-84 have been added
  • CLI instruction "logging list" has been added
  • Memory model Eeprom Page0/Byte13 has been changed
• FRAM/Eeprom Page protection:
  • Some pages are write protected and can only be written by the system itself:
    • Eeprom Page 0/Byte>=128
    • FRAM Page 0 & Page 50
  • CLI instructions (like "eeprom write") will not be able to write in protected pages
  • API instructions will not be able to write in protected pages
• Air quality values that are changing will also send an event
  • Event 2 3 has been added

V1.0.86

Date: 11/04/2021

Resolved bugs

• When 2 or more front panel buttons are pressed simultaneously, long term press actions will not be executed.

Added functionality

• BA251 has been added: This BA trigger an event, the payload of this BA will be forwarded via Event 249.
• Event 249 has been added
• Date and time related "IF THEN" BA's have been added:
  • BA100 37 has been added
  • BA100 38 has been added
  • BA100 39 has been added
  • BA100 40 has been added
  • BA100 41 has been added
  • BA100 42 has been added
  • BA100 43 has been added
  • BA100 44 has been added
  • BA100 45 has been added
  • BA100 46 has been added
  • BA100 47 has been added
  • BA100 48 has been added

V1.0.85

Date: 31/03/2021

Resolved bugs

• PSV memory relocation has been done to solve a bootloader issue

Added functionality

• Event code 0 2 has been added for Output lock change
• Event code 1 2 has been added for Input lock change

V1.0.84

Date: 25/03/2021

Added functionality

• Hardware layout for relay outputs has been made conform to the manual: Relay numbering has been modified
• Testing instructions for front panel has been added: Test system will receive the necessary messages to be able to test the front panel buttons.

V1.0.83

Date: 17/03/2021

Resolved bugs

In the Hardware design, a 24LC1025 is used as Eeprom. When multiple bytes are written in one I2C instruction, the Eeprom writes the full 128 bytes (half) page. This IC however cannot write in one I2C instruction over this half page boundary. For example, when 6 bytes are written at page 5 byte 126, you would expect that byte 126, 127, 128, 129, 130 and 131 are written. In reality, byte 126, 127, 0, 1, 2 and 3 are written. To resolve this issue, 2 things needs to be done:

• Make sure that the firmware built-in functions cannot overwrite this half page boundary by restructuring some Memory Model pages
• Make sure, in software, that the write are limited

Following changes in Memory Model have been done:

• Memory model change "Input action press 1 second":
  • Old position: Second page Byte 112-159
  • New position: First page Byte 32-79
• Memory model change "Group Action BA pages"
  • Old: 42 Basic Action consecutive per 1 page (256 bytes)
  • New: 21 Basic Action consecutive per half page (128 bytes), half page always start at byte0 or byte128.

V1.0.82

Date: 14/03/2021

Resolved bugs

• Group output follow with Argument was not working in combination with Group follow for any output change. This has been resolved in this release.

Not Resolved bugs

• In the Hardware design, a 24LC1025 is used as Eeprom. When multiple bytes are written in one I2C instruction, the Eeprom writes the full 128 bytes page. This IC however cannot write in one I2C instruction over this page boundary. For example, when 6 bytes are written at page 5 byte 126, you would expect that byte 126, 127, 128, 129, 130 and 131 are written. In reality, byte 126, 127, 0, 1, 2 and 3 are written.

Added functionality

• BA20 70 has been added
• BA20 71 has been added
• BA20 72 has been added
• BA20 73 has been added
• CLI instruction "??" and "basic action list" have been removed to optimise PSV memory
• CLI instruction "on" has been added as alias of CLI instruction "output on"
• CLI instruction "off" has been added as alias of CLI instruction "output off"
• CLI instruction "aoff" has been added as alias of CLI instruction "output all off"
• CLI instruction "el" has been added as alias of CLI instruction "error list"
• CLI instruction "ooo" has been added as alias of CLI instruction "output status on"

V1.0.81

Date: 11/03/2021

Not Resolved bugs

• In the Hardware design, a 24LC1025 is used as Eeprom. When multiple bytes are written in one I2C instruction, the Eeprom writes the full 128 bytes page. This IC however cannot write in one I2C instruction over this page boundary. For example, when 6 bytes are written at page 5 byte 126, you would expect that byte 126, 127, 128, 129, 130 and 131 are written. In reality, byte 126, 127, 0, 1, 2 and 3 are written.

Added functionality

• Group action with arguments give the possibility to use the condition of an output for example to switch leds or other outputs without using IF THEN ELSE instructions:
  • BA19 2 has been added
  • BA0 21 has been added
  • BA0 22 has been added
  • BA20 50 has been added
  • BA20 51 has been added
• Output follow action has been added:
  • When any output has been triggered, this programmed group action will be executed. Please note that this group action CANNOT contain any BA's that triggers an output since this will create a loop.
  • Memory Model Page 0 Byte 60-61 has been added
  • BA19 56 has been added

V1.0.80

Date: 23/02/2021

Resolved bugs

• In some rare circumstance, the abort function to release blocked state machines was not working properly in some edge circumstances. This could lead for example in situations where the RS485 stopped scanning. This release solves this bug.

V1.0.79

Date: 12/02/2021

Added functionality

• uCAN's changing from 1 CAN bus to another will now automatically be detected. The ping function will be broadcasted and the answer will detect the bus from which the message is coming. If the bus is changed, the CAN bus for that uCAN will be adapted accordingly. This will result in a programmed uCAN that will work on any CAN bus (directly to the Brain(+) or any of the CAN controls) and will be able to boot load independently of the connected CAN bus.

V1.0.78

Date: 12/02/2021

Resolved bugs

• A bug prevented that the uCAN connected to the Can Control could bootload. This has been solved in this release.

V1.0.75

Date: 09/02/2021

Resolved bugs

• RS485 instruction "FV" has been made conform to the specs on this wiki (22 bytes long)

Added functionality

• CLI messages have been added for following events
  • A new uCAN has been added
  • A new uCAN input has been added
  • A new uCAN sensor has been added
• BA 253 3 has been changed:
  • In previous hardware design, 12V out existed and has been eliminated in the final design so the switching capabilities have been removed from the firmware
  • This BA is now used to switch ON/OFF the CAN power of all connected CAN Control modules
  • Broadcast message has been added to switch ON/OFF power of the CAN Control modules
  • The CAN Control reports back the power status of the CAN bus
• CLI instruction "error list"
  • In the list, for every line, you can see the power status
  • If the power of the RS485 Bus has been switched OFF or a CAN Control has switched OFF the CAN Power by using the button, you will be able to see this in the "error list"

V1.0.74

Date: 06/02/2021

Resolved bugs

• When using CLI instruction "firmware version", the title of non-used module types also appeared. This is resolved in this version.

Added functionality

• BB debug mode has been added:
  • Eeprom Memory Model Page 0 Byte 13 has been added which sets the BB Debug Mode
  • When BB Debug Mode is ON, all executed BA's will also be forwarded as an event (API Instruction "EV 22") over the UART API to the BB. This allows the BB to perform full logging of all BA's being executed on Master level. The message will be forwarded as an event before the BA has been executed.
  • CLI instruction "error list" will also display the BB Debug mode.
  • API Instruction "ST" (info_type=0 and info_type=2) has been modified so BB Debug mode is included
  • Event 22 0 has been added

V1.0.73

Date: 03/02/2021

Resolved bugs

• API Instruction "BA" was also accepting messages with length different from 6 (should always be 6). When this happens now, the message will not be accepted and new error 24 will be thrown.
• API Instruction "MR" was only returning 3 correct bytes when reading FRAM, this has been resolved in this release.
• CLI Instruction "firmware version" was not always correctly working

Added functionality

• Further enhancements for using with the OpenMotics Testsystem
• FRAM writing using CLI and UART API has been limited to make sure that protected pages (0 and 50) can't be overwritten by the user or BB.

V1.0.72

Date: 19/01/2021

Resolved bugs

• When a Brain+ is initialised without Front Panel, it will be configured as a Brain. When the Front Panel is connected afterwards, the initialisation of the internal modules was not redone keeping in the Brain modules instead of the Brain+ modules. This release solves this issue.
• When input link information was directly written to Eeprom (via API), the last input module was not taken into account when performing an Eeprom activate.

Added functionality

• All the necessary CAN and RS485 instructions have been added so the Brain(+) can communicate with the test system to perform an integrated hardware test.
• Hardware E4 version has different input electronics so the firmware has been adapted to cope with this.

V1.0.71

Date: 09/12/2020

Resolved bugs

• During startup, after firmware loading, i2c errors sometimes happened. This release solves this problem.
• A not working Can Control was wrongly detected by the health check service resulting in the wrong status of the Status led.
• Improved resolving process in case of failed i2c bus

V1.0.70

Date: 08/12/2020

Added functionality

• The indicate function for external modules has been added. With the below instructions and BA's, you can let the led of the requested input, output, dimmer, sensor etc flash. The necessary CLI instructions and BA's have been added:
  • BA0 200 has been added: Output indicate (flash corresponding led if available)
  • BA1 200 has been added: Input indicate (flash corresponding led if available)
  • BA8 200 has been added: Sensor indicate (flash corresponding led if available)
  • BA10 200 has been added: Shutter indicate (flash corresponding led if available)
  • CLI instruction "input indicate" has been added
  • CLI instruction "output indicate" has been added
  • CLI instruction "sensor indicate" has been added
  • CLI instruction "shutter indicate" has been added
• CLI instruction "register list" has been added: This instruction will return the processors registers that can be used by the development team for debug purposes.
• Status led function has been modified:
  • The led will now indicate the status of the RS485 bus and the connected RS485 sales modules:
    • OFF: The Power of the RS485 bus is OFF
    • GREEN (flashing): No RS485 slave modules have been configured and the POWER of the RS485 bus is ON
    • GREEN (non flashing): RS485 modules are communicating correctly and have the health status "GOOD"
    • ORANGE (flashing): RS485 in search mode (looking for new RS485 modules)
    • ORANGE (non flashing): The initialisation mode is active and modules can be added manually
    • RED (flashing): The RS485 bus has a problem and some modules or all modules are not responding. It takes a few minutes to have modules to degrade state.
    • RED: No modules are responding and all modules have a non-good status
  • The state change from red (blinking) to green can take a few minutes since all modules must upgrade in state (all must have "good" status)
• Health status of the Micro CAN's has been added:
  • The CAN Status led of the Brain(+) will act upon the error status of the individual Micro CAN's connected on the internal bus
    • OFF: The Power of the Internal CAN bus is OFF
    • GREEN (flashing): No Micro CAN modules have been configured on the Internal CAN bus of the Brain(+) and the POWER of the Internal CAN bus is ON
    • GREEN (non flashing): All Micro CAN modules on the internal CAN bus are communicating correctly and are responding to the ping requests
    • RED (flashing): The Internal CAN bus has a problem and some Micro CAN modules are not responding.
    • RED: No modules are responding to the ping request of the Brain(+) on the internal CAN bus.
  • The Brain(+) will also check the health of the Micro CAN modules connected on Can Controls. When health will be checked by sending ping messages via the connected Can Controls. The health status detected by the Brain(+) is forwarded over RS485 API to the CAN Control. The CAN Control status led will be set based on this health information:
    • GREEN (flashing): No Micro CAN modules have been configured on the external CAN bus of the Can Control
    • GREEN (non flashing): All Micro CAN modules on the external CAN bus of the Can Control are communicating correctly and are responding to the ping requests
    • RED (flashing): The external CAN bus has a problem and some Micro CAN modules are not responding.
    • RED: No modules are responding to the ping request.
  • In the CLI instruction "Error list", the health status can be found as well.
• In the CLI instruction "error list", the electronic CAN termination status can be found as well.

V1.0.69

Date: 29/11/2020

Added functionality

• Execute list of Basic Actions through UART API:
  • API call "ES" has been added
  • This API call will allow to execute a series of Basic Actions. A Basic Action consist of following elements:
    • Type (byte): Type of action, for example all output actions have Type 0
    • Action (byte): This is the action itself, for example switch Output On or OFF
    • Device Nr (word): This is the parameter that indicates on which asset (for example output nr) the action must be executed
    • Extra parameter (word): This is an extra parameter that is used on some Basic Actions to set for example the timer of dimmer value
  • The API call "ES" will allow the same instruction (Type, Action & extra parameter) to be executed on a series of device numbers.
• BA20 105 has been added: Enable/Disable buzzer for an individual uCAN module
• BA20 106 has been added: Enable/Disable Multi Color led for all uCAN modules
• BA20 107 has been added: Enable/Disable buzzer for all uCAN modules
• uCAN modules now receive the necessary feedback from the Brain(+), when an input is pressed, to decide that non-configured inputs must beep and the corresponding leds must be turned on.
• Adding Documention
• See AIO Tips & tricks during installation and troubleshooting

V1.0.68

Date: 15/11/2020

Resolved bugs

• When on a uCAN a Temperature or Temperature/humidity sensor was connected (with brightness), the brightness sensor always gave the value 255 instead of 65535 (for a non connected brightness sensor)

Added functionality

• API Instruction "SI" (Sensor Information) has been extended with Instruction 6 (request Temperature Offset value)
• BA20 103 has been added (switch ON/OFF buzzer of Micro CAN)
• When input, sensor or module indicate is done of a Micro CAN, the buzzer will also be switch ON together with the led representation
• BA20 104 has been added (switch ON/OFF built-in multi color indication led)
• Event 21 0 has been added to receive uCAN events: For example, when a short circuit or over current situation happens on the 5V out of the uCAN, this Event will be send. When the 5V out is normal again, an other event will be send again.
• Request of Slave Firmware Version:
  • CLI instruction "firmware version" now gives Firmware version of Master and the connected Slave modules
  • The Firmware version is requested to each individual module over RS485
  • The responses are displayed on the CLI console or send through RS232 API Instruction
  • API Instruction "ST" has been extended to be able to request the Firmware version of the Slave modules
  • API Instruction "FW" have been added
  • BA 250 has been added

V1.0.67

Date: 25/10/2020

Added functionality

• CRC16 calculation for output (including Dim Control) RS485 writing has been added. This allows better integrity and avoid ghost output behaviour in extreme situations.
• On the different levels, the Dim value range that can be used is changed from 0-63 to 0-255
• Offset function for temperature has been added:
  • Offset values are stores in FRAM (page 51)
  • Basic Action 7 has been added. BA7 will set the offset and write the according value into FRAM.
  • CLI instruction "sensor list" has been modified to also display the Temperature offset
  • Every update of the temperature value (connected sensor, by using BA for virtual sensors) will be compensated by the offset value.

V1.0.66

Date: 10/10/2020

Resolved bugs

• When I2C information is read, it is only used when no errors have occurred in the I2C communication

Added functionality

• The Core has a new Front panel with modified hardware. This version supports the latest Front Panel Hardware (OMH06 B-1 CE 09/2020)

V1.0.65

Date: 07/10/2020

Resolved bugs

• "all lights off" functionality switches off all lights system wise but the remote modules did not always follow due to timings issues. This is resolved in this release.
• The Open Collector outputs on the Core did not work yet
• The input names in the CLI did not display correctly

V1.0.64

Date: 27/09/2020

Resolved bugs

• When requesting the Pulse Counter information from an input module via API or CLI, the error number counter of that module increased with 1. This is resolved in this release.

Added functionality

• CLI instruction "error list" has been modified
  • Add Voltage and current (not yet active)
  • Add 12V Out state
• 12V switching (ON/OFF) works now

V1.0.63

Date: 22/09/2020

Added functionality

• Internal pulse counters:
  • Every pulse counter is stored twice (Bank 1 and 2) in FRAM with each time a CRC16 per pulse counter to check the integrity
  • At startup, when the system is loading the pulse counter values, the CRC16 is checked in the second FRAM bank, when a problem is detected, the value is checked in the first FRAM bank
  • In this release, when an integrity problem is detected, the hour and date are stored in FRAM (Page 0 Byte 73-78) as well as the inputs that caused integrity problems (Page 0 Byte 79-80) and which inputs are correctly loaded (Page 0 Byte 81-82) by using the correct values in Bank 1 and 2.
• Output Type (Page 1-80 Byte 31-38)
  • Output type has been modified to be in line with the Classic Master

V1.0.62

Date: 20/09/2020

Resolved bugs

• When the number of output modules was put on 0 by using CLI instruction "output number modules write 0", a lot of errors appeared on the CLI console. This release resolves this bug.
• When no uCAN's are yet initialised on the CAN bus, the CAN stays led will remain OFF and will only turn red when CAN network problems or bad connection happens when uCAN's are already initialised on that bus.
• In the Eeprom/FRAM memory model, not all value were kept in big endian. Following changes have been made:
  • Eeprom: Page 1-80: Timer Output
  • Eeprom: Page 256-259: Start Group
  • Eeprom: Page 393-394: Up Timer Shutter
  • Eeprom: Page 395-396: Down Timer Shutter
  • Eeprom: Page 413-414: Shutter Group value for roller/shutter nr
  • Fram: Page 11-18: Current Shutter Position
  • Fram: Page 19: Current Shutter Group Position

Added functionality

• Pulse Counter functionality
  • Pulse counters will be kept in FRAM on the modules where it's counted. So for the inputs of the Core/Core+, the counting values will be kept on the Core/Core+. For the input module, the counting values will be kept in FRAM on the input module.
  • When a request is made from the BB for pulse counter information, that request is forwarded to the node that contains the counting data
  • API RS485 instruction "Request state of Input Module: Partial Pulse Counter Information" has been added
  • API RS485 instruction "Request state of Input Module: Full Pulse Counter Information" has been added
  • API RS485 instruction "Request state of Input Module: Input state" has been added
  • API instruction "PC" has been added to read a single pulse counter or 8 pulse counters (full module)
  • CLI instruction "pulse counter read" has been added
  • Error checking and handling has been added for modules not available
  • FRAM page 50 has been added
  • The Pulse Counters for the internal inputs are incremented when a "press" is detected
  • Every 300ms, the Master will check if any of the internal pulse counters have been incremented. When this is the case, the Pulsecounter information will be updated in FRAM including 2 bytes per Pulsecounter (CRC16 check).
  • These bytes are written twice in FRAM
  • During startup, the integrity of the Pulsecounters are checked. If One bank has a failed integrity check (for example power failure during writing), the second bank is taken to load the pulse counter information in memory and start counting.

V1.0.61

Date: 08/09/2020

Resolved bugs

• When an Output is switched ON with a timer activated, the timer value is written in FRAM once a second. A reset (hard or soft) did not load the last timer value from FRAM correctly. This is solved in this release.

Added functionality

• Added Input/Output Lock/Unlock functionality:
  • Input press/release routines have been modified so they won't be executed when an input is locked
  • Output switch ON/OFF routines have been modified so they won't be executed when an output is locked
  • Input/Output lock functionality is kept in FRAM
  • API Instruction "OD" has been modified and the Output Lock/Unlock status has been added
  • API Instruction "IC" has been modified and the Input Lock/Unlock status has been added
  • API Instruction "OC" has been added (Output Configuration)
  • Documentation
  • Locking/Unlocking is fully functional in this release

V1.0.60

Date: 07/09/2020

Resolved bugs

• For the Core+, 4 dim control outputs are available. The virtual module consist of 8 virtual outputs of which 4 are used for the Dim Control outputs available on the Core+ but the 4 non-used outputs also switched on/off leds on the Front Panel. So in this release, the 4 non used outputs will not switch ON/OFF any leds on the front panel.

Added functionality

• BA 253 2 x - has been added: Switch Power of the internal I2C bus
• BA 253 3 x - has been added: Switch Power of the external 10VDC Output
• BA 253 4 x - has been added: Switch Termination of the CAN bus on the Core/Core+
• BA 254 1 - - has been added: Perform reset of the BB via reset pin of the BB
• Memory Model Page0 Byte12 has been added: Can Bus Termination setting
• Added Input/Output Lock/Unlock functionality:
  • Memory Model FRAM: Input Pages "Input Lock/Unlock bytes" have been added
  • Memory Model FRAM: Output Pages "Output Lock/Unlock bytes" have been added
  • BA 0 250 x y has been added: Unlock/Lock Output x
  • BA 1 250 x y has been added: Unlock/Lock Input x
  • When a Lock/Unlock status of an input or output is changed, this change will also be written in FRAM memory
  • During startup, the FRAM data is read so the Lock/Unlock status is kept in the right mode
  • The CLI command "input list" has been modified that is also displays the lock status
  • The CLI command "output list" has been modified that is also displays the lock status
  • Locking/Unlocking is still in development in this release and cannot be used yet

V1.0.59

Date: 30/08/2020

Added functionality

• The Front Panel of the Core+ has a built-in Dim Control module with 4 outputs 0-10VDC:
  • Added the necessary configuration routines for the DAC5574 AD chip
  • Adding virtual module for the internal Dim Control Module
  • Linking the virtual Dim Control Module with the DAC5574
  • Linking the Front Panel leds with the Virtual Dim Control module

V1.0.58

Date: 28/08/2020

Resolved bugs

• A configuration without sensor modules generated a lot of errors on the CLI console

Added functionality

• A new type of module has been introduced: "L" and "l"
  • "L": Open Collector module
  • "l": Virtual or internal (for Core and Core+) Open Collector module
• The Core/Core+ has an additional input (5 instead of 4), this input has been activated in Firmware
• The Front Panel Hardware of the Core+ has been changed. The firmware is adapted to cope with the new hardware
• The Front Panel Hardware of the Core+ has 3 Open Collector outputs that are routed to the Mezzanine connector:
  • Those outputs have been brought together on firmware level with the 5 Open Collector outputs already available on the Core+ Hardware.
  • When those outputs are switched ON/OFF, the correct leds will indicate the status on the Front Panel.
• Front Panel Health detection added:
  • Detection when Front Panel issues are happening
  • Resolving the Front Panel issue and putting the Front Panel in normal state again
• I2C Frontpanel scanning methods has been adapted:
  • In the past, the front panel buttons were scanned every 100ms
  • In the new Hardware revision, the INT pin of both TCA9539's (of the Core+ Front Panel) have been routed to the processor
  • The Firmware has been adapted to cope with the new hardware and only read the TCA9539's when a button has been pressed

V1.0.57

Date: 12/08/2020

Resolved bugs

• Inconsistent behaviour when adding Micro CAN's on the CAN bus of the Core/Core+
• Using CLI instruction "can ping list", not all responding messages via the CAN Control were captured resulting that the Micro CAN module was indicated as "not available"

Added functionality

• BA20 1 have been added
  • Switching ON/OFF all leds of all connected Micro CAN's
  • Switching ON/OFF all status leds of all connected Micro CAN's
  • Adding mode so the Micro CAN can indicate that an input has been added and that the round trip message succeeded
• Front Panel leds
  • CAN COM led: When the Core/Core+ is receiving data on his direct CAN bus (not via Can Control), the CAN COM led will be switched ON for 400ms.
  • CAN BUS led: When no Micro CAN modules are communicating or connected to the internal CAN bus, the led will red, when normal communication is happening, this led will be green.

V1.0.56

Date: 28/07/2020

Resolved bugs

• In Automatic Module Discovery, the delay for RS485 output modules between 2 scan's wasn't high enough resulting not all modules being added. This release solves this issue.

Added functionality

• When a power or software reset is done of the Master, a search of new RS485 modules will automatically performed. When no new modules are present on the RS485 Bus, the search takes less then 200ms.
• During Automatic Module Discovery, the status led will blink orange

V1.0.55

Date: 24/07/2020

Resolved bugs

• When CLI instruction "can ping list" was used, the time indicated (in ms) was the time needed for all packets to be transmitted and received. The time now will indicate the round trip of 1 packet.

Added functionality

• Automatic Module Discovery: The system allows to add RS485 modules automatically without pressing any init button (only available for GEN3 hardware)
  • Added CRC16 check for all discovery RS485 communication so communication errors are detected and modules with wrong ID can't be added.
  • Memory Model Page0/Byte11 has been added: Enable/Disable Automatic Module Discovery. When Automatic module discovery is enabled, during startup of the Core/Core+, the system will check for new modules on the RS485 Bus. This feature only works for GEN3 hardware. If GEN2 hardware must be added, Automatic Module Discovery must be disabled and a manual add (by using the init button when the module is in discovery mode) must be executed to add such a module. Once that module is added, Automatic Module Discovery can be enabled again.
  • RS485 instruction https://wiki.openmotics.com/index.php/Master_RS485_Cummunication_Protocol#Message_when_pushing_Init_button has been modified and has CRC16 check added
  • Broadcast instruction "SU" https://wiki.openmotics.com/index.php/Master_RS485_Cummunication_Protocol#Sent_Broadcast_Message have been added so the slave modules knows when the Master has performed a reset (slave module can indicate on the status led if successful communication has been established)
  • BA 200 0 0 1 have been added (start Automatic Module Discovery)
  • CLI instruction "module discover search" have been added (start Automatic Module Discovery)
  • The Master will detect bus collisions and knows when multiple clients are responding.
  • The above feature only works with Slave modules with firmware F6.x.y
• Startup time (without Automatic Module Discovery) has been reduced from 12 to 6 seconds (the time needed to load all Eeprom parameters in RAM)

V1.0.54

Date: 12/07/2020

Resolved bugs

• Better performance and stability of the RS485 Bus
• Interrupt priorities have been adapted
• RS485 scan algorithm has been adapted to make sure all modules get's equal air time

Added functionality

• Integration of the new Can Control
  • Can Control Modules with Firmware version 6.0.23 or higher can be connected
  • Max 6 Can Control modules are allowed, each Can Control will create his own CAN segment (to connect uCAN's)
  • Max 128 uCAN's can be connected in total for all segments
  • Max 7 CAN segments (Core/Core+:1, Can Control Modules:6)
  • The Core/Core+ will convert these different CAN segments into 1 large CAN network
  • Memory model "General Configuration" (Page 0) and "CAN Slave configuration" (Page 383 and higher) has been adapted
  • CLI, API and BA instruction "error clear" also clears the Can Control errors
  • Queue has been added for all incoming CAN messages from the different CAN Control modules
  • BA20 20 have been added
  • CLI instruction "can ping list" has been modified to also include the Bus (CAN Bus: 0->Can Control 0, 1->Can Control 1, ... , 100->CAN bus of the Core/Core+)
  • CLI instruction "Eeprom ping list" has been modified to also include the Bus (CAN Bus: 0->Can Control 0, 1->Can Control 1, ... , 100->CAN bus of the Core/Core+)

V1.0.53

Date: 02/06/2020

Resolved bugs

• In some circumstances, sensor values from used sensor could be copied at non-used sensors. This version solves this problem.
• An API Event was sent every minute reporting the onboard temperature. In this release, this is changed towards an event only when the onboard temperature is changed.
• An API Event was sent twice for an output change. This is resolved in this version.
• API Instruction "TW" (Time/Date write) was not yet programmed and is now included in this release
• CLI instruction "shutter list" was not indicating the correct shutter direction (YES UP or YES DWN)
• In the shutter configuration, some bit logic was wrong writing resulting in the wrong configuration
• API Instruction "TC" gave some timing issues on the RS485 Bus resulting in bad information coming from the RS485 Bus

Added functionality

• Error 23 has been added in the error list

V1.0.52

Date: 16/05/2020

Resolved bugs

• Group actions with only 1 BA didn't work

Added functionality

• Front panel Button functionality has been extended
  • API Event 250 has been added, see https://wiki.openmotics.com/index.php/AIO_API_Event_Codes. This event will be used when Front panel button changes has been detected
  • When a button is pressed, an API Event 250 will be send
  • When a button is released, an API Event 250 will be send
  • When a button is pressed for more than 5 seconds, an API Event 250 will be send
  • When a button is pressed for more than 8 seconds, an API Event 250 will be send

V1.0.51

Date: 13/05/2020

Resolved bugs

• A bug existed in the CLI commands to write a names for example "output name write" which wrote only 1 character

Added functionality

• Group Actions:
  • In previous implementations, the end address of a group action was based on the start address of the previous group action. We've removed this and made a dedicated start and end address for each Group action.
  • Eeprom pages of the GAT (Group Allocation Table) have been changed, end address of each group has been added
  • Eeprom pages of the Group Name have been changed
  • Eeprom pages of the Group BA's have been changed
  • CLI instruction "group start write" has been changed to "group start end write" where start and end addresses can be written for a group action
  • CLI instruction "group ba read" has been added
  • BA19 201 has been added (write Group end address)
  • Documentation has been changed

V1.0.50

Date: 10/05/2020

Resolved bugs

• When using a Core or Core+ without a connected front panel, frontpanel button actions could be activated (like "module discover start" for example).

Added functionality

• Integration of the New Can Control module that support direct communication channels between the Master and the CAN/DALI Bus over the CAN Controle Module:
  • The RS485 receiving module is able to receive multiple messages from a slave. For example, when a Can Control has multiple message to transport from the Can Control queue, it can flush it immediately.
  • The RS485 drivers have been optimised allowing higher speed (less wait time between modules) and less bus errors.
  • Basic initialisation of the Can Control module is supported
  • Variable RS485 message length is supported with integrated CRC calculation
  • Additional CAN messages are introduced, see https://wiki.openmotics.com/index.php/Can_Control_RS485_Communication_Protocol#Message_Structure
• API Instruction "ST" has been extended:
  • Request of Firmware version has been added

V1.0.49

Date: 26/04/2020

Added functionality

• This firmware adds the functionality to bootload slave modules:
  • See AIO Bootloading Slave modules
  • API Instruction "ST" has been added (Status RS485 mode)
  • API Instruction "SM" has been added (Set RS485 mode)
  • API Instruction "TM" has been added (Transparent forwarding of RS485 messages from RS485 slave to BB)
  • API Instruction "TC" has been added (Transparent forwarding of RS485 messages from BB to RS485 slave)

V1.0.48

Date: 20/4/2020

Added functionality

• Front Panel leds functionality for the Core+ has been added
  • Detection Front Panel between Core and Core+
  • Correct Input/Output modules will be configured when, at startup, a Core or a Core+ is detected
  • Button functionality of the Core+ has been added
  • See AIO led and button functionality

V1.0.47

Date: 2/4/2020

Resolved bugs

• API Event "EV" message 251 and 252 (Event for changing status leds on the Front Panel) was being sent every second.
• API Instruction "GC" had the incorrect length assigned

V1.0.46

Date: 1/4/2020

Resolved bugs

• When shutters are moved up/down or stopped, the API instruction "EV" was not sent. This release solves this issue.

V1.0.45

Date: 30/3/2020

Added functionality

• Power switching:
  • Added BA253 0 -> Switch ON/OFF power of the RS485 Bus
  • Added BA253 1 -> Switch ON/OFF power of the CAN bus
  • Firmware will make sure that all communication is stopped before switching OFF one of the busses
  • API Instruction "GC" (Info_type=0) has been modified to include the power state of the RS485 and CAN bus
  • Event type 253 has been added to indicate a power change status
• I2C
  • I2C has been rewritten to more easily integrate different kind of chips
  • Blocking and non-blocking routines work on the same framework now
  • Detection of each I2C chip is done at startup
  • When a chip is unavailable, the CPU will not try to communicate with it
• Front panel leds and buttons
  • ON/OFF/Blinking functionality has been added
  • Leds can blink at duty cycle of 25%, 50% or 75%
  • Event type 251 and 252 have been added that will be sent with every change of the Front panel leds (ON/OFF)
  • BA210 has been added so the Master and BB can control the individual leds
  • Front panel functionality has been implemented: Press function, release function, long press 5s, long press 10s
  • Leds and buttons of the Core are implemented
  • Leds and buttons of the Core+ are not yet implemented
  • See AIO led and button functionality
• Detection Core/Core+
  • Depending on the Front Panel hardware, detection will be made if it's a Core or Core+ module
  • Depending if it's a Core or Core+, the right number of modules will be assigned.
  • Eeprom functionality has been modified (Page0/Byte0) so the module type can be forced (disable automatic detection of Core/Core+ which happens through the type of Frontpanel Hardware)
  • CLI instruction "error list" has been adapted to indicate which type of module it is

V1.0.44

Date: 20/02/2020

Added functionality

• The necessary modifications are made to support the Can Control module
  • "C" module has been added, separate module scanning for the CAN Control has been introduced
  • Health status for CAN module
  • Adapted CLI instructions like "error list" to display the CAN Control modules
  • BA204 has been added
  • Documentation

V1.0.43

Date: 23/01/2020

Added functionality

• This release extend the MODBUS support, see MODBUS AIO for configuration example
  • API Instruction "CS" has been added
  • CLI Instruction "input search can id" has been added
  • Documentation

V1.0.42

Date: 15/01/2020

Added functionality

• This release extended the MODBUS support, see MODBUS AIO for configuration example
  • Modbus Speed, Type and Model have been added, see Modbus Parameters
  • BA20 23 has been added
  • BA20 24 has been added
  • BA20 25 has been added
  • BA20 28 has been added
  • BA20 29 has been added
  • API Event 20 0 has been added (Event will be sent when mode and/or setpoint has been changed by slave device (=Modbus thermostat))
  • API Event 20 1 has been added (Event will be sent when mode and/or setpoint has been changed by master device (=BB or by applying certain BA's))
  • API Instruction "mR" has been added: Modbus Read
  • API Instruction "CD" has been adapted

V1.0.40

Date: 26/12/2019

Added functionality

• This release supports MODBUS thermostats
  • See MODBUS AIO
  • Sensor list instruction has been modified to include the thermostat setpoint and the thermostat mode.
  • The non-standard sensors (like T67xx (CO2), CCS811 (eCO2, VOC) and LUX sensor) are being automatically requested from the Micro CAN
  • BA20 26 has been added
  • BA20 27 has been added
  • CLI instruction “can ping list” has been modified to display the Modbus information
  • CLI instruction “can eeprom list” has been modified to display the Modbus information
  • In Memory model: Page 383-386: Modbus bytes have been added
• I2C hw reset code has been improved and made more robust

V1.0.39

Date: 27/10/2019

Resolved bugs

• Helvar and Lunatone uses a different address scheme in their application. To avoid confusion, the Lunatone Dali addressing is used and the code is adapted accordingly.
• The startup time/date and hours online were not recorded correctly anymore, this bug is resolved

Added functionality

• The necessary code has been added to read the onboard temperature sensor so monitoring of the base PCB can be done.
  • Temperature is measured every minute
  • API "EV" is sent every minute to update the temperature
  • CLI instruction "error list" has been modified so the board temperature is displayed as well
  • API or CLI instruction "eeprom activate" will read the onboard temperature immediately.
• Roller/Shutters
  • When a virtual or normal Output module is added, the output type will be checked and the correct type is automatically linked to all outputs.

V1.0.38

Date: 21/10/2019

Added functionality

• Basic Actions
  • BA21 0 has been added: DALI output OFF
  • BA21 1 has been added: DALI output ON
  • BA21 2 has been added: DALI Group OFF
  • BA21 3 has been added: DALI Group ON
  • BA21 20 has been added: Output linked with DALI Output or DALI Group
  • BA21 21 has been added: Input linked with DALI (Lunatone or Helvar) input.
  • BA21 22 has been added: Sensor linked with DALI (Lunatone) sensor.
• DALI
  • Receive protocol has been made robust so even when garbage is received, the correct DALI message are filtered and processed
  • Support of DALI motion sensors has been added
  • Support of DALI outputs (dimmed and non-dimmed) has been added
  • Some Lunatone motion sensors have built-in temperature sensors. The firmware supports polling of these temperature sensors and linking them to a virtual system temperature sensor.
  • Some Lunatone motion sensors have built-in LUX sensors. The firmware supports polling of these LUX sensors and linking them to a virtual system brightness sensor.
  • The use of DALI is described in following page: Dali AIO
• API instructions
  • Instruction "FM" is modified and will now always respond even when no answer is received on the CAN bus
  • Instruction "IC" is modified and now also contains the Dali Input Link bytes
  • Instruction "OD" is modified and now also contains the Dali Output Link bytes
  • Instruction "SI" is modified:
    • VOC information can be requested
    • CO2 information can be requested
    • Extra sensor information can be requested
    • Sensor configuration
    • Extra Sensor configuration

V1.0.37

Date: 8/10/2019

Resolved bugs

• API instruction "FS": In the "FS" response, the order in which data0..2 was sent in the wrong order

Added functionality

• Basic Actions
  • BA0 13, BA0 14 and BA0 15: These BA's will store their values (timer value and timer type) in the appropriate eeprom locations now.
  • BA10 0 has been added: Shutter x stop
  • BA10 1 has been added: Shutter x up
  • BA10 2 has been added: Shutter x down
  • BA10 3 has been added: Shutter x up-stop-up-stop...
  • BA10 4 has been added: Shutter x down-stop-down-stop...
  • BA10 5 has been added: Shutter x up-stop-down-stop...
  • BA10 20 has been added: Shutter x locked
  • BA10 21 has been added: Shutter x stopped & locked
  • BA10 22 has been added: Shutter x up & locked
  • BA10 23 has been added: Shutter x down & locked
  • BA10 24 has been added: Shutter x unlocked
  • BA10 100 has been added: Shutter x is linked to output duo nr y
  • BA10 101 has been added: For shutter x, if y=0 -> first output of duo is UP, second is DOWN, if y=1 -> first output of duo is DOWN, second is UP
  • BA10 102 has been added: For shutter x, set timer y (in seconds, max 255) for direction UP (time needed from 100% to 0%)
  • BA10 103 has been added: For shutter x, set timer y (in seconds, max 255) for direction DOWN (time needed from 0% to 100%)
  • BA10 104 has been added: For output duo x, set duo as OUTPUT when y=1, set duo as SHUTTER when y=0
  • BA10 105 has been added: Link shutter x with shutter group y
  • BA10 106 has been added: Unlink shutter x with shutter group y
• CLI instructions
  • CLI instruction "shutter list" has been added
  • CLI instruction "shutter group link list" has been added
  • CLI instruction "shutter name read" has been added
  • CLI instruction "shutter name write" has been added
• Output module in Roller/shutter mode
  • When an output module is added in Roller/Shutter mode, the output status of the 8 output is automatically changed to Shutter mode (BA10 104)
• Shutter groups
  • Max 16 shutter groups can exist, every shutter can be part of 1 or more shutter groups (or even can be part of all shutter groups)
  • Shutters that are linked to a shutter group can be lock/unlocked together or moved (up/down/stop) together
  • When moving a group of shutters, first will be checked if any shutters of this group are already moving, then those shutters will be stopped and a delay of 500ms will be applied before those shutters are activated (up or down) again.
  • Shutter can be locked and shutter groups can be locked. When a shutter group is locked, the individual group and the shutters inside that group can't be used anymore until unlocked.
• API instructions
  • Instruction response "GC" info_type=1 has 2 extra parameters: Max_shutters and Max_group_shutters
  • API instruction "sD" has been added

V1.0.36

Date: 21/9/2019

Resolved bugs

• API instruction "FS" reported the wrong length

Added functionality

• Roller/Shutter functionality
  • A consecutive set of 2 outputs (0&1, 2&3, 4&5, 6&7 etc) can be used as normal outputs or as Roller/shutter outputs (never both can be ON at the same time). When the user tries to switch ON both, those outputs will be switched off.
  • Eeprom Page 391 is used to link the Roller shutter Nr with the Output Nr
  • When an output duo is configured as roller/shutter and no shutter timer has been set, standard 255 seconds will be applied.
• 32K PSV memory limit
  • The PSV memory has a limit of 32k to store all constants. Since this stores the text information of the BA's as well as the CLI instruction, this limit was reached
  • In this release, The CLI instructions are stored in ROM in stead of PSV.
• FRAM functionality
  • Roller shutter data like lock status, movement direction, position etc is stored in FRAM and retrieved at reset
  • The timer values of all outputs are kept in FRAM when a light/output is ON. When a reset occurred, the timer is kept and the count down is continued after startup.
• API instructions
  • Instruction "FM" will now always respond with CID=1
  • When an "eeprom activate" is successfully executed, an event ("EV") will be sent, see https://wiki.openmotics.com/index.php/AIO_API_Event_Codes

V1.0.35

Date: 6/8/2019

Resolved bugs

• Functions like "output all off" didn't always switch off all outputs on the RS485 modules.
• API commands "DL" and "GC" didn't respond.
• When an input was pressed or released, the same API "EV" was sent.
• API command "EV" did report the wrong timer value when an output was changed.
• API command "MR" was missing 1 byte in the response string

Added functionality

• FRAM support:
  • Add queueing for FRAM writes
  • Status outputs (status + dimmer value) are stored in FRAM
  • At startup, the FRAM Output Status values are retrieved and the outputs are restored in the status (including dimmer value) before the reset or power outage
  • At startup, the current Time and Date is written so we know when the last startup or system reset has occurred
  • The number of uptime hours are being kept in FRAM. Every hours, this is written in FRAM.
  • Uptime, firmware version & startup time/date is displayed in "error list".
  • Page 0 is protected now and can't be changed by using CLI/API instructions.
• RS485 bus stability
  • The bus was acting too fast and giving the modules not always enough time to answer resulting in some bus errors
  • Eeprom value (Page0 Byte8) has been added which gives the number of ms between each scan of a module
  • With this value, the Bus speed can be modified and tuned if needed.
  • The standard value works for the most common environments
• Module Type
  • Module type has been added so the BB knows which kind of module is initialised
  • Module type has been added in "error list"
  • Module type has been added in API instruction "MC"

V1.0.34

Date: 28/7/2019

Added functionality

• API instruction "OD" (Output Detail) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• API instruction "IC" (Input Configuration) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• API instruction "MC" (Module Configuration) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• API instruction "GC" (General Configuration) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• API instruction "TW" (Write Time and Date) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• API instruction "TR" (Read Time and Date) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• API instruction "DL" (Device List, Output and Input status) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• Error queueing has been improved
  • Error list has been extended, see https://wiki.openmotics.com/index.php/Error_List_AIO#Error_codes_AIO
• API Events ("EV") have been added for input press and input release, see https://wiki.openmotics.com/index.php/AIO_API_Event_Codes

V1.0.33

Date: 25/7/2019

Resolved bugs

• Removing CAN bus when AIO was in ON state and after 10 minutes, reconnecting didn't bring back the CAN bus. CAN bus now comes back after +/-1 minute.
• When the power was applied and the date was not yet set for the first time, the Clock always started at 00:00:00. This release fixes this issue.
• With the CLI instruction "sensor list", in rare events, ghost values appeared (strange values for non connected sensor). The values remained correct in memory but were wrongly displayed. This release fixes this issue.

Added functionality

• API instruction "EV" (Event) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• API instruction "ER" (Error) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• API instruction "SI" (Sensor Information) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• API instruction "MR" (Memory (Eeprom) Read) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• API instruction "MW" (Memory (Eeprom) Write) has been added, see https://wiki.openmotics.com/index.php/API_Reference_Guide_AIO
• New state machine checks sensor health every 2 minutes, if a sensor is not responding, API message ERR will be send
  • This has been added for uCAN sensors
  • This has been added for sensors connected to the Openmotics Temperature module
• If a sensor is not responding, the sensor value will be put on NA
• CLI instruction "health debug on" and "health debug off" has been added, see https://wiki.openmotics.com/index.php/CLI_Reference_Guide_AIO
  • When a sensor is not reporting a value, this will be printed on the console when health debug is on
  • When a sensor is not reporting a value, an API ER message will always be sent to the BB even when health debug is off
• CLI instruction "change debug on" and "change debug off" has been added, see https://wiki.openmotics.com/index.php/CLI_Reference_Guide_AIO
  • When a sensor has received a value that is changed towards the old known value, and change debug is on, a message will be printed on the console
  • When a sensor has received a value that is changed towards the old known value, an API EV message will always be sent to the BB even when the debug function is off.
  • When an output receives a trigger to update his values (output state, timer, dimmer), and change debug is on, a message will be printed on the console.
  • When an output receives a trigger to update his values (output state, timer, dimmer), an API EV message will always be sent to the BB even when the debug function is off.
• Sensor (temperature, humidity, brightness) follow function for non-can sensors has been added including the debug functions.