Difference between revisions of "AIO Release Notes"
|Line 8:||Line 8:|
== V1.0.57 ==
== V1.0.57 ==
=== Resolved bugs ===
=== Resolved bugs ===
Revision as of 10:41, 12 August 2020
- 1 General
- 2 V1.0.57
- 3 V1.0.56
- 4 V1.0.55
- 5 V1.0.54
- 6 V1.0.53
- 7 V1.0.52
- 8 V1.0.51
- 9 V1.0.50
- 10 V1.0.49
- 11 V1.0.48
- 12 V1.0.47
- 13 V1.0.46
- 14 V1.0.45
- 15 V1.0.44
- 16 V1.0.43
- 17 V1.0.42
- 18 V1.0.40
- 19 V1.0.39
- 20 V1.0.38
- 21 V1.0.37
- 22 V1.0.36
- 23 V1.0.35
- 24 V1.0.34
- 25 V1.0.33
The Master firmware for the AIO will be published as Open Source once the module goes on sale.
firmware version to read the Master Firmware version.
- 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 Group Name have been changed
- Eeprom pages of the Group BA's have been changed
- 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:
- Basic initialisation of the Can Control module is supported
- Variable RS485 message length is supported with integrated CRC calculation
- 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)
- 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
- 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%
- BA210 has been added so the Master and BB can control the individual leds
- 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.
- 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 Instruction "mR" has been added: Modbus Read
- API Instruction "CD" has been adapted
- This release supports MODBUS thermostats
- See MODBUS AIO
- 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
- 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.
- 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.
- Support of DALI motion sensors has been added
- Support of DALI outputs (dimmed and non-dimmed) has been added
- The use of DALI is described in following page: Dali AIO
- API instructions
- 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
- 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 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
- Shutter groups
- 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
- Eeprom Page 391 is used to link the Roller shutter Nr with the Output Nr
- 32K PSV memory limit
- In this release, The CLI instructions are stored in ROM in stead of PSV.
- FRAM functionality
- API instructions
- Instruction "FM" will now always respond with CID=1
- 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
- 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
- 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"
- Error queueing has been improved
- 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
- CLI instruction "change debug on" and "change debug off" has been added, see https://wiki.openmotics.com/index.php/CLI_Reference_Guide_AIO