* Add RGB Led management for errors, infos, and send receive events
Add RGB led management for indicators, integrate it for M5 Atom and ESP32 C3 and S3 dev board
Update Fastled version to 3.5.0.
The default behavior is with regular LED, to use RGB Led the macro RGB_INDICATORS needs to be define, along with the FASTLED_IND_TYPE, FASTLED_IND_DATA_GPIO and FASTLED_IND_NUM_LEDS
Note that some RGB led need to have a different color scheme, so in this case it can be entered along with the data PIN definition: -DFASTLED_IND_DATA_GPIO=27,GRB
* Add FastLed library to the environments
to suggest 3.3V wiring instead of Vin, as Vin may not be always connected to the USB port on the development boards, also remove ESP8266 BT images (not supported anymore), also add mention to Heltec SX127X boards
* Bump Theengs Decoder to v095
* IBT-4XC inclusion by @DigiH in #208
* ThermoPro TP359 by @DigiH in #210
* IBS-TH1 external probe differentiation by @DigiH in #211
* CGG1 firmware extension by @DigiH in #218
* Otio/BeeWi BSDOO by @DigiH in #214
* Add OpenHAB3 tutorial and BLE binary
* Small text changes
Just a few small text changes, also writing out OMG as OpenMQTTGateway, probably clearer for new to OMG users.
Co-authored-by: DigiH <github@digih.net>
* Bump Theengs Decoder to v0.6.1
* Differentiate a FASTLed environment
* remove BT from the nodemcuv2-all-test env as it is already tested into nodemcuv2-ble
* Decoder 0.6.2
Co-authored-by: DigiH <github@digih.net>
* Publishing/receiving inconsistencies
* General platformio.ini changes
General platformio.ini changes to allow for publishing/receiving settings to be defined in User_cofig.h instead of them only working if defined in the environments. Kept separate so far for discussion.
If you are on Linux and don't want to (or can't) install Chrome based browser to flash you can use the Python based flash tool from Espressif.
It took me some searching and reading the docs of esptool to get the commands to work, then I thought I can save this time for others by adding the relevant info to this how to.
* Use a task to process immediate BLE actions to prevent MQTT disconnection if the action takes too long to complete.
* Add state_on and state_off parameters to createDiscovery
* Add ability to specify pulse length in ZactuatorONOFF
Add an additional parameter to the MQTT message to control the actuatorONOFF pulse length e.g. `mosquitto_pub -t home/OpenMQTTGateway_MEGA/commands/MQTTtoONOFF -m '{"gpio":15,"cmd":"high_pulse","pulse_length":25}'`
* Simplify initialization of pulselength
This allows for connecting to devices that do not use the MAC address type 0.
This also adds the logging of the "mac_type" so it is visible to users trying to connect to broadcasting devices.
Additionally this will allow for future connectable devices using a MAC address type other than 0 to be automatically connected to
when support is added for them, similar to LYWSD03MMC etc..
* Add immediate parameter to BLE connection commands.
When sending a command to read/write a characteristic on a BLE server this adds a new parameter to cause the action to be
performed immediately. This will stop the scan in progress to perform the actions queued.
Example use:
```
mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m '{
"ble_write_address":"AA:BB:CC:DD:EE:FF",
"ble_write_service":"cba20d00-224d-11e6-9fb8-0002a5d5c51b",
"ble_write_char":"cba20002-224d-11e6-9fb8-0002a5d5c51b",
"ble_write_value":"TEST",
"value_type":"STRING",
"ttl":4,
"immediate":true }'
```
Stop BLE processing when immeditate command sent.
* Use a shorter connection timeout.
* Update docs.
* Remove MQTT spam for connection retrys
* Prevent crashing when the normal connection process occurs at the same time as an immediate action.
* Use a semaphore to protect BLE device vector.
Florian