AIO Release Notes
- 1 General
- 2 V1.0.73
- 3 V1.0.72
- 4 V1.0.71
- 5 V1.0.70
- 6 V1.0.69
- 7 V1.0.68
- 8 V1.0.67
- 9 V1.0.66
- 10 V1.0.65
- 11 V1.0.64
- 12 V1.0.63
- 13 V1.0.62
- 14 V1.0.61
- 15 V1.0.60
- 16 V1.0.59
- 17 V1.0.58
- 18 V1.0.57
- 19 V1.0.56
- 20 V1.0.55
- 21 V1.0.54
- 22 V1.0.53
- 23 V1.0.52
- 24 V1.0.51
- 25 V1.0.50
- 26 V1.0.49
- 27 V1.0.48
- 28 V1.0.47
- 29 V1.0.46
- 30 V1.0.45
- 31 V1.0.44
- 32 V1.0.43
- 33 V1.0.42
- 34 V1.0.40
- 35 V1.0.39
- 36 V1.0.38
- 37 V1.0.37
- 38 V1.0.36
- 39 V1.0.35
- 40 V1.0.34
- 41 V1.0.33
The Master firmware for the AIO will be published as Open Source once the module goes on sale.
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.
Date: In development
- API Instruction "BA" was also accepted 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.
- Further enhancements for using with the OpenMotics Testsystem
- FRAM writing using CLI and UART API has been limited to make sure essential pages (0 and 50) can't be overwritten
- 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.
- 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.
- 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
- 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)
- The led will now indicate the status of the RS485 bus and the connected RS485 sales modules:
- 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.
- The CAN Status led of the Brain(+) will act upon the error status of the individual Micro CAN's connected on the internal bus
- In the CLI instruction "error list", the electronic CAN termination status can be found as well.
- 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
- 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)
- 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
- 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.
- When I2C information is read, it is only used when no errors have occurred in the I2C communication
- The Core has a new Front panel with modified hardware. This version supports the latest Front Panel Hardware (OMH06 B-1 CE 09/2020)
- "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
- 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.
- CLI instruction "error list" has been modified
- Add Voltage and current (not yet active)
- Add 12V Out state
- 12V switching (ON/OFF) works now
- 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
- 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
- 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.
- 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 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)
- Locking/Unlocking is fully functional in this release
- 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.
- 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
- 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
- A configuration without sensor modules generated a lot of errors on the CLI console
- 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
- 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"
- 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.
- 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.
- 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
- 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.
- 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)
- 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
- 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+)
- 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
- Error 23 has been added in the error list
- Group actions with only 1 BA didn't work
- 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
- A bug existed in the CLI commands to write a names for example "output name write" which wrote only 1 character
- 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
- When using a Core or Core+ without a connected front panel, frontpanel button actions could be activated (like "module discover start" for example).
- 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
- 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)
- 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
- 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
- When shutters are moved up/down or stopped, the API instruction "EV" was not sent. This release solves this issue.
- 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 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
- 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
- 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
- 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
- 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
- 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
- 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.
- 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.
- 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.
- 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
- API instruction "FS": In the "FS" response, the order in which data0..2 was sent in the wrong order
- 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
- API instruction "FS" reported the wrong length
- 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
- 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
- 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"
- 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
- 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.
- 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.