Specifically, this will break RFM69_SUPPORT on case insensitive
filesystems due to the RFM69.cpp from the RFM69 lib being ignored
when adding ESPurna's rfm69.cpp
- provide a generic way to read default status of the pin after boot
allows us to use switch as both on and off, independent of the position on boot
- add BUTTON_DEFAULT_LOW & BUTTON_DEFAULT_BOOT (now it's not just BUTTON_DEFAULT_HIGH)
wiki described raw numbers for some reason :/ this will break that
- clean-up 'constexpr const' and 'const' function args, both are redundant
- clean-up debounce event member defaults, put things in the header
- platform == platform_latest
- mcspr/toolchain-xtensa via https://github.com/platformio/platformio-core/issues/3612
Yet, this does not avoid useless warnings that platform does
not specify platformio/* prefix in the package spec :(
It should be available in the next espressif8266 version:
0859336019
alexa device discovery/state calls use URL of type
/api/hash_id_key_whatever/lights
This is blocked when API is disabled and fails
also when http API is enabled because no apikey is
sent by amazon calls
Don't try to use the http api for alexa calls.
Responses for alexa are done by fauxmoesp lib,
so there's no need for the http api call.
- Add ::Released button event to be used specifically with switches, opposite of ::Pressed
- Always use default state for switches instead of ignoring it and using current pin reading as value. This allows us to boot with the switch held in the opposite state and trigger the correct event immediately
(meaning, switches now depend on the BUTTON_DEFAULT_HIGH presence to detect the default position)
- BREAKING: Fixup hardware.h. Any custom board needs manual changes.
- BREAKING: Rework MQTT button messages to send text from debug messages instead of numeric code
resolve#2327, #2220
- remove legacy support in the webui
- format datetime strings on the device, use NTP panel to display them both
- migrate from the old ntpOffset + ntpDST + ntpRegion to ntpTZ
ensure the only operation from main loop() is load
since isr handles incrementing the counter, resulting value is calculated as
offset between the current and the previous reading (always positive)
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"
```
Max Prokhorov
Alex. Tircovnicu
aL1aL7
Nicolas Gilles
tom-kaltofen
imgbot[bot]
user176176
Bert Vermeulen