Optimize isr handler once more by removing gpio -> index conversion at runtime
Drop atomics for now, since we can also make the whole operation atomic
by locking GPIO interrupts while reading and setting the counter value
And we don't have another thread / core to worry about
resolve#2368
- Fixes "undefined reference to `__atomic_fetch_add_4'"
Notably, std::atomic_fetch_add(&counter, 1) would also trigger this.
std::atomic<T>::operator+= does not allow in-place change, since it
returns T instead of T&
- Another work reduction in the isr, treat 'value' as `counter > 0`
instead of relying on the notion that we can sometimes read the value
with very low counter frequency
- Fix duplicated initializations
- Buttons events source as button property instead of a global one
- Rename events source -> provider for all settings, consistent with the other things like relay and light providers
- AnalogPin to read between a certain analogRead() range
Trying to follow defaults here - analog 'press' is digital LOW, default value is HIGH, so no additional cfg entries are needed besides pin, level and changing evt source
- (debug) Refactor gpio command, add adc to show analogRead(pin)
- (debug) Add button command
Implemented based on:
https://gitter.im/tinkerman-cat/espurna?at=5f5d44c8df4af236f902e25dhttps://gitter.im/tinkerman-cat/espurna?at=5f60e7f1f969413294e95370
Always do digitalRead() after ISR
Drop trigger, since we can handle this inside of reading routine
(although, pending some changes to make reading interval per-sensor)
Rework read / write through std::atomic
- make sure we call run() before checking for errors, we will miss status update otherwise and lock the sensor class in the error state that it cannot recover from
- set error flag only when either bsec or bme680 report an error. ensure we show any issues reported by the library via the debug log
ref. https://gitter.im/tinkerman-cat/espurna?at=5f63a955c1d1a53705abcbe3
TODO: add custom error messages through virtual method?
Also, a minor fix to the sensors test when using 1m and 2m boards
- support 32 byte hostname / ssid
- support 64 byte passphrase
- slightly reduce amount of memory allocations
- tweak initialization paths to call persistent(false) as early as possible
Provide safe fallback *only* when char is out-of-range
As it is, numeric 0 was equal to else { ... }, so 00 was never parsed.
Previously, it was assumed that we never try to parse leading / trailing zeroes,
but in turn we also ignored zeroes in the middle of the number...
* Add support for the Zhilde ZLD-64EU-W
This is a power outlet with 6 power sockets and 4 USB ports.
* fixup based on the zld-44eu hw and tasmota template info
Co-authored-by: Maxim Prokhorov <prokhorov.max@outlook.com>
trying to fix#2343
*** [.pio\build\$PIOENV\firmware.bin] TypeError
`expected str, bytes or os.PathLike object, not Dir' trying to evaluate `${__get_flash_size(__env__)}'
as it turns out, PIO platform internals (sometimes) did not use the correct ldscript path
vector will not copy when move ctor is marked noexcept
remove the copy ctor 'trick', re-add dtor. explicitly do the thing we want
(...clang-tidy would've shown this issue, something to do in the CI...)
see 69c65a6a40 (commitcomment-42008295)
Because of the way DHCP is integrated into the Core logic, we need to
call wifi_softap_add_dhcps_lease(...) inbetween WiFi.softApConfig(...) and WiFi.softAp(...)
- magnitudes vector grows by calling copy ctor, ensure filter never gets deleted
- ensure we can't use magnitude member instead of ctor arg
- more magnitude references instead of using index access
- additional checks for isnan, fix report never triggering
- drop event callback. at least for EventSensor, we already have
report with min / max value change triggers
- BaseFilter must have virtual dtor
- magnitude object is not trivial, we need to manage filter lifetime
- Ensure move also moves filter object
- Clean-up using magnitude object by value in functions
- (experimental) provide generic way to read magnitude values
- expose /api/metrics with values formatted specifically for prometheus, with relay and sensor data
- small tweaks to sensor init
Example config:
```
scrape_configs:
- job_name: 'espurna'
metrics_path: '/api/metrics'
params:
apikey: ['apikeyapikey']
static_configs:
- targets: ['espurna-blabla.lan:80']
```
Where ESPurna side has
```
apiKey => "apikeyapikey"
apiEnabled => "1"
```
ref. https://travis-ci.com/github/mcspr/espurna-nightly-builder/jobs/378203413#L698
> +env ESPURNA_FLAGS=-DGENERIC_ESP01_512KB ESPURNA_RELEASE_NAME=generic-esp01-512kb ESPURNA_BUILD_SINGLE_SOURCE=1 pio run -e esp8266-512k-base -s -t release
> /home/travis/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: .pio/build/esp8266-512k-base/firmware.elf section `.irom0.text' will not fit in region `irom0_0_seg'
Remove ~90Kb from the build.
- cache received rfbridge codes in the internal list, allow to operate on it via the rpn operators
- add `<N> <proto> <code> rfb_match`, matching when we receive specified protocol + code string at least N times
- add `<proto> <code> <proto> <code> rfb_sequence`, checking if specified protocol + code pairs happen in sequence
- add `<TIME> <N> <proto> <code> rfb_match_wait` - similar to `rfb_match`, but waiting for at least `TIME` (ms) via oneshot runner
- add `<proto> <code> rfb_info`, pushes code's latest timestamp and it's counter on the stack
- add `<proto> <code> rfb_pop`, which removes the specified protocol + code from the internal cache
- fix MQTT skip setting making RPN variables absent on initial connection
- default to no skip when receiving MQTT
(small issue still stands with us having non-clean MQTT session, broker will persist variable subscriptions even after unsubscribe event)
- build flags RF_... are renamed to RFB_...
- drop RFB_DIRECT boolean in favor of RFB_PROVIDER=..., adds RFB_PROVIDER_EFM8BB1 and RFB_PROVIDER_RCSWITCH
- rework rfbridge parser. drop serial buffering and combined processing of rcswitch / rfb data in favor of state-full parsing
- rework rcswitch integration, support variable length payload via bitlength and allow to output 64bit data via rc-switch fork from open-mqtt-gateway.
- apply bit-length comparison for the old rcswitch codes, bump cfg version to 5 to allow 1.14.1 config updates (broken on dev, since cfg setting was never updated on clean installations 😞)
- optional relay support for both, independent of mqtt
- rework settings scanning routine when trying to match rf payload with the relay ID, scan settings only once instead of relayCount()<sup>2</sup> times if we want to find something for relayCount()-1'th relay
- add broker callbacks list with proto id + stringified code. default rfbridge does not support more than one protocol, so send out ID 0 as default (which matches with what 0xa6 will show, supposedly as it does not work for me :?)
- send out 0xa6 and 0xb0 sniffer data from https://github.com/Portisch/RF-Bridge-EFM8BB1/ to the MQTT and internally via broker callback
- update receiver callback 'locking' to make sure specific relay ID is tracked instead of all at once
- update build tests and deprecation notices
Stock RFBridge & RCSwitch refactoring are closely related, so pulling all of this at once. We no longer use the same 'flow', using separate integration paths.
One sort-of breaking thing is the new internal _rfbMatch() change - we no longer update serialized 'buffer' string when matching in the receiver, thus we (very) likely send a different string to the MQTT when receiving the same device's code. This introduces non-trivial dependency on the output buffer though :/ And we don't always have relay support, so that would be another layer of preprocessor checks.
Instead, I am in favor of another option - special build / runtime setting to provide the same protocol + payload pair as new broker integration does. To simplify / make sure it is noticed, separate protocol and actual data with comma, colon (like IR) or space.
Alex. Tircovnicu
Max Prokhorov
Nicolas Gilles
imgbot[bot]
user176176
Bert Vermeulen