Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new webcam driver over latest dev. #19280

Merged
merged 6 commits into from
Aug 22, 2023

Conversation

btsimonh
Copy link
Contributor

@btsimonh btsimonh commented Aug 8, 2023

Description:

To use the old one, define USE_WEBCAM_LEGACY

This is a re-submisison of the webcam PR, with the implementation of it changed to by default replace the old one, making this PR generate a directly testable and usable binary.

Runs all camera stuff from a task.

Never fails at startup on my (very bad) esp32cam board.

Enables motion detect, Timelapse, direct image saving etc. from Berry scripts and as TAS commands.

Increased reliability. Increased flexibility.

Documented here: https://github.com/btsimonh/TasmotaBerryPLay/blob/master/tasdocs/esp32cam.md

Example Timelapse and Motion here (needs more description, but works very well. Can use staticfileserving from the other PR to provide direct viewing and download of complete image sets.

Should work with Scripts, but not tested for a while (@gemu2015 ?).

Checklist:

Checklist:

  • The pull request is done against the latest development branch
  • Only relevant files were touched
  • Only one feature/fix was added per PR and the code change compiles without warnings
  • The code change is tested and works with Tasmota core ESP8266 V.2.7.4.9
  • The code change is tested and works with Tasmota core ESP32 V.2.0.10
  • I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 8, 2023

see #19015 for info on the previous PR.

The cam ran on that PR for 28 days (and is still running on that).

This PR is the exact same driver, pasted on top of current dev. I have not done extensive testiing on latest dev....

@gemu2015 - I would appreciate your thoughts and feedback, as the originator of the original driver, and a great inspiraiton. I beleive I've solved some of the underlying issues with some boards (lack of reset line), but also made signifiant improvement in reliability by accessing stuff only from one place. Also, I hope it still fully supports your Scripts based stuff - but now does support Berry, with a few extra features for reading poictures, etc. directly which will enable use with possible current/future AI technologies, as well as sending images to remote locations (e.g. google drive, or ftp). Happy to discuss any time.

@btsimonh btsimonh mentioned this pull request Aug 8, 2023
6 tasks
@gemu2015
Copy link
Contributor

gemu2015 commented Aug 9, 2023

@btsimonh

i am busy with other things, but made a short check with my s3cam.

  1. got compile error when ENABLE_RTSPSERVER is not defined.
  2. with task driver i didn't get the cam initialized
  3. legacy driver got picture without script, but none with script

have to check in more detail what is wrong, but will take some time

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 9, 2023

thankyou @gemu2015 - I will fix the compilation thing with RTSP disabled tonight, and re-check and post my user config.
What was the user config you used?
Ref the legacy driver, there have been no changes for some time... there were some mutexes added some time back - maybe these affected the script video display? I'll try to review the commits...

@gemu2015
Copy link
Contributor

gemu2015 commented Aug 9, 2023

now also compiled for esp32 cam and it works with and without script.
on my esp32s3 legacy also works now.
however task version crashes and i later have to open the case for serial reflash.
my s3 cam is however a very special build since it also uses bidirectional audio.
on power on i hear strange cracklings from the speaker as if i2s is failing.
probably your version is interfering with i2s ?
if i find the time i will build a version without audio and try again

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 9, 2023

hmm.. it could be that by putting the cam in a separate core/thread, it's starving the i2s audio processing. Certainly, the cam does run 'as fast as it can' - e.g. at max framerate if not transferring the video anywhere.
Check the shared I2C enabling too - not sure if this has any impact, but Theo enabled it by default a few months ago.
"task version crashes" - if you have serial on it, maybe we get a crashdump?

@btsimonh
Copy link
Contributor Author

@gemu2015 - I just ordered the required audio modules (I hope they are right).
https://www.amazon.co.uk/dp/B07TSC1QCH?psc=1&smid=AWLU8WJU8S0VS&ref_=chk_typ_imgToDp
https://www.amazon.co.uk/dp/B08BCHHZPN?psc=1&smid=AWLU8WJU8S0VS&ref_=chk_typ_imgToDp
You can never have too many toys!

@gemu2015
Copy link
Contributor

does not seem to be related to i2s however. disabled all audio code and got the result below
Seems to be an S3 implementation incompatibility.
S3 cam driver is very different from standard ESP32. (see CAM driver source code)

00:00:00.000 HDW: ESP32-S3 (PSRAM)
00:00:00.006 UFS: FlashFS mounted with 10244 kB free
00:00:00.010 CFG: Loaded from File, Anzahl 18
00:00:00.016 QPC: Count 1
00:00:00.017 SCR: ufilesystem found
00:00:00.024 Projekt tasmota - webcam Version 13.0.0.2(tasmota)-2_0_10(2023.08.12 12:38:01)
00:00:00.607 WIF: verbinden mit AP1 WLAN-7490 Channel 1 BSSId CC:CE:1E:61:99:91 in Modus 11n als sonoff-6016...
00:00:02.477 WIF: verbunden
00:00:02.728 HTP: Web-Server aktiv bei sonoff-6016 mit IP-Adresse 192.168.188.88
12:46:13.710 MQT: Verbindungsversuch...
12:46:13.858 MQT: verbunden
12:46:13.859 MQT: tele/sonoff/LWT = Online (beibehalten)
12:46:13.861 MQT: cmnd/sonoff/POWER = 
12:46:13.863 MQT: tele/sonoff/INFO1 = {"Info1":{"Module":"ESP32S3","Version":"13.0.0.2(tasmota)","FallbackTopic":"cmnd/webcam_fb/","GroupTopic":"cmnd/tasmotas/"}}
12:46:13.874 MQT: tele/sonoff/INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"sonoff-6016","IPAddress":"192.168.188.88","IP6Global":"","IP6Local":"fe80::6ab6:b3ff:fe21:3780"}}
12:46:13.896 MQT: tele/sonoff/INFO3 = {"Info3":{"RestartReason":"Software reset CPU","BootCount":6}}
12:46:17.079 QPC: Reset
12:46:17.934 MQT: tele/sonoff/STATE = {"Time":"2023-08-12T12:46:17","Uptime":"0T00:00:08","UptimeSec":8,"Heap":246,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Wifi":{"AP":1,"SSId":"WLAN-7490","BSSId":"CC:CE:1E:61:99:91","Channel":1,"Mode":"11n","RSSI":56,"Signal":-72,"LinkCount":1,"Downtime":"0T00:00:03"}}
12:46:53.549 UPL: Datei Config_s3cam_12.0.2.3-2.dmp
12:46:53.586 UPL: erfolgreich 4096 bytes
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x40056ea0  PS      : 0x00060e30  A0      : 0x8002f1fd  A1      : 0x3fceb9d0  
A2      : 0x00000000  A3      : 0x00000000  A4      : 0xffffffff  A5      : 0x00000000  
A6      : 0x00000000  A7      : 0x00000002  A8      : 0x00000000  A9      : 0x3fcebaf0  
A10     : 0x3fce9710  A11     : 0x00000000  A12     : 0x3fc9dc38  A13     : 0x00000000  
A14     : 0x00000001  A15     : 0x00000000  SAR     : 0x0000001c  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000000  LBEG    : 0x40055601  LEND    : 0x4005560e  LCOUNT  : 0xfffffff4  


Backtrace: 0x40056e9d:0x3fceb9d0 |<-CORRUPTED

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 12, 2023

Yep, it uses rom based jpg routines - so some of my modified conversion routines may not 'fit' (but should not be run in the above log).
Also uses a different clock scenario, and a different gpio setup routine.

1/ would you be happy with a #define which enforces legacy for S3 until it can be resolved (probably when you have more time...)?
2/ the most likely parts are the assertion of pwdn pin in wcSetup. Try commenting those?
Do the addresses in the core dump take us anywhere useful in the map file?

br, Simon

Edit: I took the plunge and bought this one: https://www.amazon.co.uk/gp/product/B0BMQ8F7FN/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
At least then I may be able to he;p a bit in diagnosis.

check pin_pwdn before using it n 0x105!!!
@btsimonh
Copy link
Contributor Author

fixed without RTSP build, and a small change around us of pin_pwdn (like, don't use it if it's not configured...).

@btsimonh
Copy link
Contributor Author

@gemu2015 - do I need some special config for it to find layer3.h when USE_SHINE is enabled for audio?
Do I need USE_SHINE?

@gemu2015
Copy link
Contributor

@btsimonh
USE_SHINE is an mp3 encoder needed for mp3 coding of a microphone if you want mp3 (unidirectional) streaming or storing of mp3 audio files.

Audio Bridge does not require MP3, it uses binary streaming over UDP (bidirectional, half duplex).

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 13, 2023

I'm thinking my first usecase for audio would be just bringing it to the web interface - seems this is supported, but uses the mp3 encoder :(. I'll try again with a full clean & build, and if that fails, examine the build files in more detail (complete rebuild really stresses my 10 yr old 8gb i7). My second use case MAY be to look at streaming the audio with the video over RTSP, but that's much more involved, coordinating the video and audio, capturing the timestamps, and modifying the rtsp library for the muxing.

New toys should arrive later today.
In prep for me building for S3, could you post your S3 build config? i.e. user_config_override and platform_override, and which tasmota32 you build?

@gemu2015
Copy link
Contributor

gemu2015 commented Aug 13, 2023

Video with audio would be very cool.
ESP32 MP3 audio transfer slows down video to 1/3 frame rate
while on ESP32-S3 there is no remarkable reduction in frame rate. (s3-cam should be your next toy :-))

i was working on a door station with bidirectional audio which works very well with audio.
i adapted the fastest display i could get with 20 ms full display update rate, but could not get
a fluent video display from the cam to the display, only about 1-3 frames per second.

i postponed this now and leave it to other folks.

@gemu2015
Copy link
Contributor

#define USE_WEBCAM
#define USE_WEBCAM_LEGACY
#define MP3_MIC_STREAM
#define USE_I2S_MIC
#define USE_SHINE
#define USE_I2S_AUDIO
#define MP3_STREAM_PORT 83
#define MIC_CHANNELS 2
#define I2S_BRIDGE

remark:
SHINE encoder only works with 32khz and up, so we either must define 2x16 or 1x32 kHz channels

@btsimonh
Copy link
Contributor Author

@gemu2015 - what board do you build for S3? Seems if I just build S3, I get no PSRAM, but if I build tasmota32s3-qio_opi-all I get lgvl.h errors from scirpter. Now trying a modified tasmota32s3-qio_opi-all.... I have it 'working' but seems wifi and cam interfere, but maybe because no PSRAM.

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 14, 2023

fixes put in place such that S3 does not crash on startup.
I Used

[env:tasmota32s3-qio_opi-all]
extends                     = env:tasmota32_base
board                       = esp32s3-qio_opi
board_build.f_cpu           = 240000000L
board_build.f_flash         = 80000000L
build_flags                 = ${env:tasmota32_base.build_flags}
#                              -DUSE_WEBCAM
                              -DUSE_BERRY_ULP
#                              -DFIRMWARE_LVGL
#                              -DUSE_LVGL_OPENHASP
                              -DOTA_URL='""'

to get PSRAM running.
Now the camera works, but web access is not great. Issues were the lack of pwdn pin, but still using it's (-1) value.
My template:
{"NAME":"ESP32S3-FNK085","GPIO":[1,1,1,1,5024,5056,5120,5152,5090,5089,5091,5088,5092,5184,1,4992,5095,5094,5093,1,1,1,0,0,0,0,0,8800,8832,8864,1,1,1,1,1,1,1,1],"FLAG":0,"BASE":1}

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 14, 2023

@gemu2015 - your opinion on S3 webserving timings appreciated.
I killed my task, and it's still really bad - see discussion in general. My 'normal' esp32 is still not as good as a ESP8266.... what kind of HTTP response time did you get on your original firmware? e.g. just going from main menu to consoles?

Edit: I have reproduced your exact mediation error - investigating. The reason there is no backtrace is because it's at task destruction.

@btsimonh
Copy link
Contributor Author

@gemu2015 - pls try again.
For me, my wifi on S3 is terrible - If I attenuate it a bit (finger on antenna), it becomes near perfect.
But cam now works quite well when wifi is ok.

@gemu2015
Copy link
Contributor

@btsimonh
compiled with your last build and s3cam now works with and without script. i am having no wifi issues at all.
however also the old legacy driver never had any problems with my s3 cam

according to wifi issues keep in mind that the cam clock line is a severe source of interference with the wifi signal. all my cam problems i had also with esp32 cams came from that line (provided a stable power supply)

i also have had wifi issues with my rgb display (sunton) also from interference with high speed display clock. i had to adjust display clock to minimize this effect.

@btsimonh
Copy link
Contributor Author

tried wcclock 10, and initial results are good. at the default of 20, i was gettgin twice the framerate I expected (50 at low res?), so maybe the s3 somehow runs the clock line faster.... will report on stability now.

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 15, 2023

note. wcclock 11 or 12 gives better results than wcclock 10. So I guess 10mhz is bad... and detuning it is better. (1-200 ms web response at 10, 30ms resonse at 11.) For my hardware ... and wifi interaction :(

11-> not great (14/27fps).
12-> ok (30/30fps).
13-> not great
14-> very good
15-> very good.
16-> fail (wifi dead, serial needed to change wcclock)

edit: testing more values this morning.
26 seems quite OK. ~60fps at lower res, some frame skips, but <30ms web response time.

@btsimonh
Copy link
Contributor Author

@arendst - I'm pretty happy with this now. It's fine on S3 - with the caveat that my board's clock line is very noisy as the observations above indicate.
All my stability and wifi concerns have been resolved with the understanding that the XCLK line frequency caused them all.

Over the coming weeks, I'll look at an autoconf for my specific board; I beleive that autoconf runs some berry at startup, and so could pre-configure the clock.

I have concerns over the webcam driver as a whole - but they apply to both new and old. e.g. if there is no pin config, it will default to something close to the AIThinker board, and this could in theory prevent full boot. I think it would be better in the absence of pin config to not try to start the camera hardware. It may also be better to have a default wcclock which is detuned from 20mhz, since 20mhz seems to be a bad one for wifi interferance. But ALL sample code has 20mhz.... so maybe that's the recommended for the cameras.

The new driver does allow wcresolution -1 to prevent camera startup.

One thing of general note for ESP32 (maybe only S3?) was that one issue I discovered was that an addLog() very close to a task ending caused a guru mediation (invalid access). I added an (excessive) delay after the addLog(), and never saw the issue again. This may have implications for other use of tasks on TAS. It appears that addLog within a running task is fine - it's just if that class terminates very shortly after the addLog. I looked at the logging source, and could not see anything obvious, but it's as though we're keeping a pointer to task memory, and using it after addLog returns (i.e. in this case task termination).
This could have implications beyond tasks.

br, Simon

@btsimonh
Copy link
Contributor Author

p.s. I did not experiment with audio as well yet. It will be a few months before I can get to play with those new toys...

@barbudor
Copy link
Contributor

@btsimonh are you calling addLog in your camera thread?
If yes, I am not surprised of bad side effects. Tasmota and it's functions are meant to be ran from a single thread. The is no lock mechanism on resource access so if tasmota core thread is doing an addLog at the same time your camera thread does, bad things are highly expected.
A delay shouldn't change anything

@btsimonh
Copy link
Contributor Author

@barbudor - addLog is protected by a mutex in ESP32, so should be safe. It's been heavily tested in BLE some years ago, but maybe not this specific circumstance of a thread ending.

@Jason2866
Copy link
Collaborator

My 2 cents. The standard Webcam driver setup should only include the Webcam feature.
Tasmota way. Keep it small and simple by default. Enhanced features (motion detection....) consuming flash and RAM should only be enabled via compile time settings, like it is done fore the rtsp stuff.

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 21, 2023

@Jason2866 - I could re-work again to slim down, disable motion, but I'd like to leave the TAS commands for picture saving/reading jpeg in for Berry use.

What I'd have in mind is:

1/ Add #define for motion
1b/ Add `#define' for picture manipulation (encode/decode - only really required for motion and advanced AI related possible future features). Check and remove crossover with @arendst 's existing JPEG decode routines, which I think I reproduced independently :(.
2/ disable the driver unless pins are configured (I feel danger in the defaults as many modules have different pins)
3/ add a pin type for CAM_PWR - I've only just realised that this is different to CAM_PWDN. CAM_PWR on AIThinker boards controls the actual 2 voltage regs - nothing to do with the camera as such, but does enable the board to go into a low(er) power draw. CAM_PWDN is a camera control line, often not connected. The esp cam driver is not designed to toggle the CAM_PWR line, hence the 0x105 errors. (I'm looking at if we can deepsleep, and so run timelapse off battery).
4/ Allocate the main control structure only if enabled - so saving RAM if the driver is not enabled.
5/ maybe move motion into ANOTHER task, so that it's use does not affect framerate. i.e. minimise related cam thread processing to picture capture to the buffer, but process the buffer analysis seperately.
6/ move all motion code to a different file so the basic driver is easier to maintain?
7/ detailed code-size reduction.

I do not anticipate any major feature changes, except for the motion being optional.
The only 'extra' feature which would be REALLY nice would be to test and tune audio with video, but I don't see this as achievable within this step (e.g. I'd like to investigate audio in the RTSP, and real-time audio stream to the main menu or a dedicated browser-style interface, so enabling a 'door bell' style device. In theory it will work to browser now, but in practice I beleive it will need some tuning).

But... I'll be out of action for about a month from wed (holiday then business), so it's not going to be quick, unless I had help. I would guess that the revision could be available in 8-12 weeks, or 16 weeks to include some further long-period tests.

So we have three options ref this PR:

1/ put on hold and anticipate a future update.
2/ publish as is to get feedback, and anticipate a future update.
3/ change such that inclusion of the 'new' driver is controlled by an additional `USE_WEBCAM_2" rather than be the default, publish and hope for feedback.

I'm happy with any of the above, although getting feedback on performance and features would be nice.
A list of real cam use cases would also be really good, so we know where the focus should be. (maybe run a poll?)

Size comparison:

(expand to understand @Jason2866 's valid concerns).

Build Size comparison

Bases on building WITHOUT scripts (since with scripts includes motion code linking...).

DRAM increases by 172 bytes.
Flash increases by 13.7 KBytes.
Total image size increase by 13668 bytes.

'new' driver:

Total sizes:
Used static DRAM:   64820 bytes (  59760 remain, 52.0% used)
      .data size:   21076 bytes
      .bss  size:   43744 bytes
Used static IRAM:   89894 bytes (  41178 remain, 68.6% used)
      .text size:   88867 bytes
   .vectors size:    1027 bytes
Used Flash size : 1189556 bytes
           .text:  948971 bytes
         .rodata:  240329 bytes
Total image size: 1300526 bytes (.bin may be padded larger)

'old' driver:

Total sizes:
Used static DRAM:   64692 bytes (  59888 remain, 51.9% used)
      .data size:   21108 bytes
      .bss  size:   43584 bytes
Used static IRAM:   89894 bytes (  41178 remain, 68.6% used)
      .text size:   88867 bytes
   .vectors size:    1027 bytes
Used Flash size : 1175856 bytes
           .text:  938855 bytes
         .rodata:  236745 bytes
Total image size: 1286858 bytes (.bin may be padded larger)

V2 driver with motion features removed:
(compared to old driver)
DRAM -11Kbytes
IRAM -148 bytes
Flash -8052 bytes

Used static DRAM: 53548 bytes ( 71032 remain, 43.0% used)
.data size: 21076 bytes
.bss size: 32472 bytes
Used static IRAM: 89746 bytes ( 41326 remain, 68.5% used)
.text size: 88719 bytes
.vectors size: 1027 bytes
Used Flash size : 1167804 bytes
.text: 933723 bytes
.rodata: 233825 bytes
Total image size: 1278626 bytes (.bin may be padded larger)

@arendst
Copy link
Owner

arendst commented Aug 21, 2023

As it's esp32 it's not so much the size increase but the possible lack of complete compatibility with the current driver. For me I feel you tend to go a long way to add features you need while losing the compatible and possibly legacy functionality.

I suggest to keep your driver as a V2 version for users feeling comfortable to use it while keeping the current driver for all current users feeling comfortable with it's current performance.

@btsimonh
Copy link
Contributor Author

@arendst - I agree with you. In this case I strived to retain every existing feature, but it's not possible to test them all without help, and for those from whom I need the help most, time is a precious comodity.
Tonight or early tomorrow, I will update to swap the USE_WEBCAM_LEGACY to USE_WEBCAM_V2 and reverse the meaning, such that the default will be the original driver.

@btsimonh
Copy link
Contributor Author

I did an hour of work to separate the motion features, and (see sizes added to above) there is a significant saving (8k reduction of flash compared to release driver. 11k reduction of DRAM compared to release driver), even over the original driver. I did not try to run it yet, but it builds fine with and without motion. I suggest this is a worthwhile effort regardless of which is default. Let me test a little, and if it's the same as the PR for normal and S3, I'll update as above, but also with the separation (separate .ino file for motion, so making it simpler as well).

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 21, 2023

All done.
Logging minimised too.
use

#define USE_WEBCAM_MOTION
#define USE_WEBCAM_V2

to enable and enable all features.

@Jason2866
Copy link
Collaborator

Jason2866 commented Aug 21, 2023

Fine for me now 👍 Like the performance gain!
Btw. my S3 Cam has no clock wifi issues. Can use every clock rate without issues. Overclocking with 24 MHz is no problem. Even 26 MHz does work. But picture gets darker with this clock rate.
Another EDIT: Does work with experimental Tasmota Arduino core 3.0 (IDF 5.1)

@btsimonh
Copy link
Contributor Author

btsimonh commented Aug 22, 2023

@Jason2866 - thankyou for running it up. I believe that my S3 board is hardware compromised (Freenove - I'll report to them at some point, they seem quite responsive. I got s/n 85, so it's a fairly new board for them). They ran XCLK all around the houses. At some point I'll remove the pin on that GPIO to reduce the stub.
Ref the new arduino core, I did not try it.

Edit:
I have updated the basic documentation of the additional features here: https://github.com/btsimonh/TasmotaBerryPLay/blob/master/tasdocs/esp32cam.md

@arendst arendst merged commit c9b5e5a into arendst:development Aug 22, 2023
60 checks passed
@btsimonh
Copy link
Contributor Author

thankyou @arendst :).
please make sure @btsimonh is mentioned against any issues or questions.
I'll be away for a couple of weeks now, but mentions go into my main work email, so I will see them upon return.

@belveder79
Copy link

belveder79 commented Aug 26, 2023

I installed the new development snapshot and it works really decently... I did not test any of the motion features, but from what I saw so far it is soooooooo more stable and faster compared to the other version - amazing...

PS: just a thought, because the question about the potential applications came. up. I'm using multiple of those cams in a PTZ fashion, driving the 2 servos through berry like this. The real problem I have is that it is hard to get control buttons right into the Tasmota interface - did not find an easy way to do so yet...
I also have the AI on the Edge running on one of them... overall they try to emulate a lot of the Tasmota behaviour... so any "simple enough" AI stuff could also be interesting...

@btsimonh
Copy link
Contributor Author

btsimonh commented Sep 9, 2023

@belveder79 - using Berry, you should be able to serve a simple html webpage from the SD card or flash. This would then allow you to create a page dedicated to the PTZ control, rather than use the webui as a basis.
It's also easy enough to add a button in the webui which redirects to the PTZ page. Since most of these devices have plenty of filesystem flash and probably an SD card, the html filesize is not a problem...
( if you dig through https://github.com/btsimonh/TasmotaBerryPLay you will find my webcam berry timelapse code, which includes adding such a link button (web_add_main_button()), and it has an HTML - not accessing the live image, and served using static file serving, not via Berry reading and serving the file - but it's a simple example. )

@belveder79
Copy link

@btsimonh very cool, will check out... thx

eckelj added a commit to rddl-network/Tasmota that referenced this pull request Sep 21, 2023
* Berry `var` allowed in with walrus operator `:=` (arendst#19018)

* Berry `var` allowed in with walrus operator `:=`

* fix regression

* Revert "Berry `var` allowed in with walrus operator `:=` (arendst#19018)" (arendst#19019)

This reverts commit 8f06552.

* Implement deepsleep(0)

Implement deepsleep(0) as command ``restart 9`` (arendst#19024)

* Update change logs

* Partition Wizard is now able to convert to safeboot from Shelly partition layout (arendst#19034)

* Update changelogs

* Hot fix for gitpod and CI  (pio core v6.1.8 is faulty) (arendst#19044)

* Use pio v6.1.7

* Accelerate path.listdir() (arendst#18927)

* Accelerate path.listdir()

* restore old behavior, push filename only and not the full path to the list

* Revert "Hot fix for gitpod and CI  (pio core v6.1.8 is faulty) (arendst#19044)" (arendst#19051)

This reverts commit c4f899a.

* Create GC9A01_display.ini (arendst#19043)

* Fix to Partition_Wizard for shelly (arendst#19056)

* Fix BUG: Zigbee devices cannot be added through routing nodes (arendst#19036)

* `BrRestart` now supports web handlers to work after Berry restart (arendst#19057)

* ESP32 LVGL library from v8.3.7 to v8.3.8 (no functional change) (arendst#19058)

* ESP32 LVGL library from v8.3.7 to v8.3.8 (no functional change)

* Update changelog

* Matter increase logs in save_fabrics (arendst#19060)

* Enhance ZC-Dimmer for falling and leading edge dimmer (arendst#19054)

* Update tasmota_types.h

* Update xdrv_68_zerocrossDimmer.ino

* fix modbus-tcp, add U32,U64 etc (arendst#19063)

* Berry added `getgbl` performance counter to `debug.counters()` (arendst#19070)

* Berry add `getgbl` counter

* Berry added `getgbl` performance counter to `debug.counters()`

* Matter fix bug when saving Force Static endpoints (arendst#19071)

* Matter improve latency for remote commands (arendst#19072)

* Matter increase logs when storing sessions (arendst#19073)

* Enable ESP32 shutter driver

Enable ESP32 shutter driver (arendst#18295)

* Bump version v13.0.0.2

Update changelogs

* Set ESP32-C3 max supported ADC channels to 5

* Matter add mini-profiler (arendst#19075)

* Update changelogs

* Update decode-status.py to synchronize SetOption154/155 (arendst#19078)

I noticed that the translation for SetOption154/155 bits did not match tasmota_types.h:
https://github.com/arendst/Tasmota/blob/development/tasmota/include/tasmota_types.h#L190-L191

* Matter fix session not being removed from memory (arendst#19081)

* Matter fix session not being removed from memory

* Fix

* File UI changes (arendst#19014)

* Remove recursion into folders on Manage Files.  May be enabled with UFILESYS_RECURSEFOLDERS_GUI.  On Edit of a file, Save and Magane btuttons return to the folder containgint the file being edited.  On delete file, UI returns to the folder that the deleted file was in.

* Make newfile put in in the current folder, and return to current folder on save of manage button.

* Add folderOnly and FileOnly functions to reduce code duplication.
Enable folder delete.
Enable folder listing to be aborted (x in browser)
Disbale ESP32 Download Task.  Needs attention.
Allow folder create from newfile name.

* Configuration file save and restore .xdrvsetXXX

Configuration file save and restore now backup and restore ``.xdrvsetXXX`` files too (arendst#18295)

* Berry `_class` can be used in `static var` initialization code (arendst#19088)

* Verify correct functionality

* Update changelogs

* Berry minor fixes from upstream (arendst#19091)

* Fix driver config restore

* Fix driver config backup and restore

Fix driver config backup and restore (arendst#18295)

* Fix possible buffer overflow

* Zero-Cross Dimmer fixes (arendst#19109)

* Fix Zero-Cross flickering on Savedata

* Fix reboot on DIMMER usage with Zero-Cross

* Fix Flickering on dimmer 0

* Berry add `energy.update_total()` to call `EnergyUpdateTotal()` from energy driver (arendst#19117)

* Sync with Berry upstream (arendst#19119)

* Berry extend `range(lower, upper, incr)` to arbitrary increment (arendst#19120)

* Update Berry windows exe to latest (arendst#19121)

* Berry updated syntax highlighting plugin for VSCode (arendst#19123)

* Berry check arguments for `range()` (arendst#19124)

* Berry fix syntax highlighting for escaped chars (arendst#19126)

* Fix typo

* Berry update grammar (arendst#19129)

* More user-friendly defaults for DisplayMode and DisplayDimmer (arendst#19138)

Changing default for DisplayMode from 1 to 0. Users are getting confused by the display doing something they did not ask for (and not being aware of DisplayMode). This got worse with LVGL/HASPmota displays becoming common, with users having much less reason to dive into the old DisplayXxxxx commands. And it may even be hard to see that it is even a display of time/date causing the display to flicker.

Changing default for DisplayDimmer from 10% to 50%. The low brightness of 10% is not always easy to see, especially in daylight. 50% is generally better, while not going "full blast" with 100%.

* Berry add metrics for memory allocation/deallocation/reallocation (arendst#19150)

* Zigbee DIYRuZ_Geiger (arendst#19151)

* Berry `tasmota.loglevel()` and `tasmota.rtc_utc()` for faster performance (arendst#19152)

* Berry add AES CCM decrypting in a single call to avoid any object allocation (arendst#19153)

* New DEEPSLEEP topic for HA + Battery Level % support (arendst#19134)

* New LWT on deepsleep

To allow better integration into HA LWT topic will report details of sleep status:
16:54:04.388 MQT: hm/tele/ESP_3284D1/LWT =
{"Sleep":{"Time":"2023-07-17T16:55:03","Sleep":1689612844,"Wakeup":1689612903}}

* Revert LWT back to non JSON

Send DeelSleep on LWT
Send Deepsleep parameters on topic DeepSleep

* Setting default for batteryLevel

* Enable BatteryPercentSet

Changing the battery level e.g. by rule

* Added Battery % to status message

* added battery_level_percent

* Added battery % support in STATE message

* Enable setting battery level

101 is reserved for power-plug. No battery Level reported

* Setting default for battery Level

101 is reserved for power plug
0..100 normal battery values

* Revert back LWT to Offline

Removed "DeepSleep" LWT status until further decision is made. Current implementation is technical sufficient for HA to detect a battery powered device

* Added discovery message after deepsleep change

* Added discovery for battery and deepsleep

* Matter latency improvement for single attribute reads and single commands (arendst#19158)

* Solidified Code updated

* Fix default battery level

- Fix default battery level (arendst#19160)
- Bump version to v13.0.0.3

* Update changelogs

* Fix compilation (arendst#19134)

* MAX17043 sensor integration (arendst#18788)

* Restart MAX17043 from the scratch

* revert change

* Changed battery capacity in charge (capacity is the Ah value of the battery, this degrades over time when battery ages)

* merge

* Changing xsns_109 to 110

* fix nr

* removed old xsns109

* Update I2CDEVICES.md

* clean-up usage of Interface

* Update change logs

* Berry SK6812_GRBW crash (arendst#19166)

* Update italian language (arendst#19169)

* changing reference to xsns109 (arendst#19170)

* fix empty line problem (arendst#19171)

* Update de_DE.h

* Refactor MAX17043 driver

* Refactor MAX17043 driver

Refactor MAX17043 driver optional enable library (default off providing smaller footprint (-250 bytes)

* Add alternative for PCA9685

Add alternative for PCA9685 as define PCA9685_V2 (arendst#18805)

* Update changelogs

* Core 2.0.11 (arendst#19181)

* Update changelogs

* Berry `mqtt.publish` now distinguishes between `string` and `bytes` (arendst#19196)

* Berry improve tasmota.scale_uint() (arendst#19197)

* Make TCPStart ip filter more IPv6 friendly (arendst#19199)

* IRremoteESP8266 library from v2.8.5 to v2.8.6 (arendst#19212)

* ensure minimum interrupt time (arendst#19211)

prevent interrupts <30 micro seconds because sometimes see crashes on esp8266.
esp32 stop of interrupt >30microseconds and < 105microseconds

* Zigbee decode Aqara 0000/FF01 attribute 03 as Temperature (arendst#19210)

* Zigbee decode Aqara 0000/FF01 attribute 03 as Temperature

* Changed to AqaraTemperature

* Four files which used #ifdef EPS8266 instead of #ifdef ESP8266 - which e.g. broke the MFRC522 functionality between 12.5 and 13.x. (arendst#19209)

* Auto detect flash size and adjust FS (arendst#349) (arendst#19215)

* Reduced log level for TeleInfo (arendst#19216)

* unsigned overflow fixed (arendst#19221)

fixed overflow on negative value with dimmer 100%

* Fix fabric saving exception (arendst#19224)

* Berry bytes `get` and `set` work for 3 bytes values (arendst#19225)

* Berry bytes `get` and `set` work for 3 bytes values

* Fix error message

* fix 4MB PIO script upload regression

* Matter increased polling frequency for local switches/occupancy (arendst#19242)

* Fade would fail when the difference between start and target would be too small (arendst#19246)

* Matter support for fabric_filtered request (for Google compatibility) (arendst#19249)

* Update changelogs

* Integrate MAX17043 driver mechanisms in xsns_110 (arendst#19219)

* Fixing SHUTTERINVERT issues (arendst#19243)

* fix wrong inverted shutter

* fix inverted shutter for esp32

* Update changelogs

* Matter support for large atribute responses (arendst#19252)

Support for responses (arrays) that do not fit in a single UDP packer
Do not remove children fabrics

* Matter fix auto-configuration Relay indices (arendst#19255)

* Update changelogs

* Change console height

Change console height from default 318 pixels to viewport (arendst#19241)

* Save some more code bytes

* add wifitest3 (arendst#19259)

* Zigbee Berry minor fix and cleaning (arendst#19257)

* Zigbee Berry minor fix and cleaning

* Fix compilation

* Fix compilation when IPv6 is not supported (arendst#19260)

* Fix console min height

* Fix console Firefox layout

* Change shutterbutton hold behavior with grouptopic (arendst#19263)

* skip stop on hold if grouptopic

If shutterbutton is defined with a grouptopic send on HOLD, there is no stop on releasing the button. All shutters will move to defined position

* do not stop on hold release if group submitt

If mqtt broadcast is defined on hold then release the hold button will not anymore stop the local shutter. All shutter will move to defined position

* Update ru_RU.h (arendst#19214)

* Prepare for Arduino v3 / esp-idf v5 (arendst#19264)

* Bump version to v13.0.0.4

* Prepare for Arduino v3 / esp-idf v5 2nd batch (arendst#19265)

* Tasmota based on Arduino 3.0.0 (arendst#19270)

* more idf5.1 preps: Berry SPI (arendst#19273)

* Improvements to thermostat debug output (arendst#19279)

* add: update DEBUG_THERMOSTAT to only control the virtual switch

Also, debug output is still generated but end user can control this debug level 3

* add: debug output of main controller parameters when thermostat enabled

Also, add units for debug outputs added to make them more intelligible

* Update xdrv_39_thermostat.ino

* add: debug message when sensor is detected as not alive

fix: display thermostat number in debug messages

* add: log message prefix string for thermostat

* Update xdrv_39_thermostat.ino

fix: typos in comments
add: debug messages

* add: debug prefix for thermostat

* add: debug prefix added to output lines

* fix: comment typos and small grammatical changes for clarity

* add: debug prefix 'THE' added to debug output

* add section safeboot_flags in platform_tasmota32.ini (arendst#19281)

This will make it easier to ignore a bunch of libraries in order to speed up builds without polluting the ENV sections too much.

Usage:
[env:my_safeboot_env]
lib_ignore              = ${safeboot_flags.lib_ignore}

* use common safeboot flags (arendst#19282)

* fix IRAM_ATTR specified both in function declaration and definition (arendst#19286)

* Improvements to PID controller driver (arendst#19285)

* add: update DEBUG_THERMOSTAT to only control the virtual switch

Also, debug output is still generated but end user can control this debug level 3

* add: debug output of main controller parameters when thermostat enabled

Also, add units for debug outputs added to make them more intelligible

* Update xdrv_39_thermostat.ino

* add: debug message when sensor is detected as not alive

fix: display thermostat number in debug messages

* add: log message prefix string for thermostat

* Update xdrv_39_thermostat.ino

fix: typos in comments
add: debug messages

* add: debug prefix for thermostat

* add: debug prefix added to output lines

* fix: comment typos and small grammatical changes for clarity

* add: debug prefix 'THE' added to debug output

* add:  display PID status and key info on web output

* fix: remove extraneous comments that included unused code fragments

* add: local sensor handling improvements

add: define a local sensor name
add: define the local sensor measurement parameter
add: limit sensor not seen error message to every 60 seconds to avoid flooding the logs
add: include interval since which sensor data was last updated
fix: properly update the maximum interval time so missing sensor data is properly alerted

* Update xdrv_49_pid.ino

* Typo architceture → architecture (arendst#19288)

* avoid unnecessary compiling of specific libraries in lib32_div for most builds (arendst#19293)

* ESP32: pass flashmode at build time to macro definition (arendst#19299)

* pass flashmode at build time to macro definition

* fix 8266 builds

* fix: properly detect device is offline after maximum misses reached (arendst#19298)

* Update changelogs

* [DS18x20] Enhance use of aliases (arendst#19026)

* [DS18x20] Enhance use of aliases

`defineDS18x20_USE_ID_AS_NAME`:
Always show part of the address, even for one sensor
`#define DS18x20_USE_ID_ALIAS`:
The command `DS18Alias` can now be use with alphanumeric aliases, which replace the sensor name

* [DS18x20] change to calloc()

* fix OneWire for IDF5.1 and C2/C6 (arendst#19303)

* fix OneWire for IDF5.1 and C2/C6

* Use Onewire in arduino30 builds

* use SOC specific defines for C2,C3 and C6

* Removes software based no load threshold. (arendst#19302)

Lowers ADE7953 builtin no load detection threshold to be able to measure 5 watt power levels.

* Update changelogs

* Creates a place to put the customer boards (arendst#19309)

* Add commands to allow setting of timeprop parameters (arendst#19310)

* add: commands to set timeprop settings

* Update my_user_config.h

* fix: properly generated json response to commands

* Sync dev with release v13.1

* Update platformio_tasmota32.ini (arendst#19313)

* add: shutdown command for PID controller (arendst#19318)

* Add variables to rules

Add variables ``%power<1..28>%`` and  ``%switch<1..28>%`` to rules (arendst#19331)

* Update switch comments

* fix shutterinvert (arendst#19341)

* fix shutterinvert

* fix shutterinvert

* Update changelogs

* Changed display invert setting

Changed display invert setting after tasmota start in uDisplay driver (arendst#19337)

* add platformio_tasmota_core3_env.ini to gitignore

* Remove debug messages (arendst#19365)

* Fix compile warning

* Phase 1 support C2/C6

* Phase 1 support C2/C6

* Phase 1 support C2/C6

* Phase 1 support C2/C6

* Add new webcam driver over latest dev. (arendst#19280)

* Add new webcam driver over latest dev. To use the old one, define USE_WEBCAM_LAGACY

* enable build without RTSP.
check pin_pwdn before using it n 0x105!!!

* more fixes around pwdn.  Make wcresolution -1 set the resoltuion setting to 'disbale cam' value (15).

* fix task stop - wait for debug to leave-> prevents guru. pin task to core 0.

* split motion from other code.  Add USE_WEBCAM_MOTION to control inclusion of motion code (big hit). Change from using USE_WEBCAM_LEGACY to USE_WEBCAM_V2

* logging minimisation - behind WEBCAM_DEV_DEBUG

* Shutter ESP32 fixes (arendst#19362)

* fix esp32 shutter

* fix shutterinvert+shutterbutton

* Phase 2 support C2/C6

* ignore esp-nimble-cpp (arendst#19369)

in core 2.0.11

* Phase 2 support C2/C6

* Fix Core 3 compilation

* Fix Core 3 compilation

* prepare transition to esp-nimble-cpp (arendst#19370)

* Platform ESP32 2023.08.01 (arendst#19371)

* Neopixel add SPI driver for C2 and some minor updates (arendst#19372)

* fix inverted shutter inconsistencies (arendst#19374)

* inverted shutter fix on overflow

* fix inverted_shutter > 9

fix on inverted shutter at esp32.
fix tilt behavior on inverted shutter

* fix tilt behavior on inverted shutter

* do not use NimBLE-Arduino for Mi32-legacy (arendst#19375)

* Fix compilation

* Arduino.3.0: enable Audio libs compile by disabling incompatible I2S driver (arendst#19377)

* i2s off for Arduino 3.0

* fix compile of uDisplay with IDF5.x on ESP32S3 (arendst#19378)

* Fix idf chip revision

* Revert "Fix idf chip revision"

This reverts commit e5cb367.

* Teleinfo power fix (arendst#19381)

* fix power arendst#19244

* cosmetic display

* Fix idf chip revision

* Fix crash of uDisplay on  ESP32S3 with IDF5.1 (arendst#19383)

* fix compile of uDisplay with IDF5.x on ESP32S3

* fix crash with uDisplay on S3 with IDF5.1

* Consolidate esp32 hardware info

* Finally add ESP32-P4 ;-)

* translate label (arendst#19385)

* Update change logs

* Fix rotary edge cases (arendst#19164)

* Fix crash in IRHVAC (arendst#19389)

* Update changelogs

* Allow ADE7880 user defines (arendst#19391)

* Fix IRHVAC crash v2

* Added passive mode for Sen5x sensor (required for Ike@ Vindstyrka) (arendst#19388)

* Added a passive mode in sen5x sensor for parasitic installations. This skips reset & initialization of sensor on startup and reduces the polling to every 10 seconds to not interfere with and confuse the other I2C master on the bus, e.g. Ike* Vindstyrka.

* Removed obsolete updateCount. Cleanup.

* Update decode-status

* EnergyMargins - always send MQTT telemetry message (arendst#19397)

* Add twilight info to GUI (arendst#19334)

* fix and improve pzem_dc (arendst#19402)

* enable more driver for Arduino 3.0

* More Arduino 3.0 env

* Final change to GUI twilight

* Fix xdrv_122_file_settings_demo buffer overflow (arendst#19405)

* expected changes for arduino30 (arendst#19421)

* Add ESP32-C6 GPIO26/28 in template

Add ESP32-C6 GPIO26/28 in template as Red pins used by flash (QIO) but optionally free if DIO/DOUT

* Allow display of revision v0.0

* build safeboot bin for C2/C6 (arendst#19422)

* build safeboot bin for C2/C6
* add C2/C6 safeboot to CI
* Enable core3 env settings before Pio starts

* Revert "build safeboot bin for C2/C6 (arendst#19422)" (arendst#19423)

This reverts commit f840f51.

* Build C2/C6 safeboot firmwares in GH Actions (arendst#19424)

* Added compiler option for doubleclick window (arendst#19428)

* sorry... (arendst#19429)

* Fixed PCF8574 mode 1

- Fixed PCF8574 mode 1 with base relays exception 3/28 regression from v12.4.0.4 (arendst#19408)
- Bump version v13.1.0.2

* Support for HDMI CEC protocol (arendst#19434)

* Berry fast_loop is now called every 5ms whatever the Sleep value (arendst#19436)

* all output parts for I2S and IDF5.1 (arendst#19440)

* Update italian language (arendst#19442)

* Berry make mdns compatible with non-IPv6 builds (arendst#19444)

* Berry move solidified code to C (arendst#19446)

* Fix compilation on Arduino 3 (arendst#19447)

* Fix compilation on Arduino 3

* Fix compilation

* Berry cleaned udp class (arendst#19449)

* Berry move mapping from C++ to C (arendst#19450)

* Reduce IRAM consumption of HDMI CEC to 1453 bytes (arendst#19452)

* Reduce IRAM consumption of HDMI CEC to 1453 bytes

* Add changelog

* enable IPv6 and Matter (arendst#19456)

* Fix migration error to filesystem settings (arendst#19454)

* `Sendmail` upgraded to ESP-Mail-Client v3.4.9 from v1.2.0, using BearSSL instead of MbedTLS (arendst#19460)

* `Sendmail` upgraded to ESP-Mail-Client v3.4.9 from v1.2.0, using BearSSL instead of MbedTLS

* Fix compilation on ESP8266

* Fix compilation

* fix compilation

* fix shine for gcc12 (arendst#19458)

* Enable ESP Mail Client in core 30 (arendst#19461)

* Enable multipress events on buttons (arendst#19465)

* Update changelogs

* Support for IPv6 link-local zones for esp-idf 5.1 (arendst#19469)

* cosmetic changes only (arendst#19468)

- reorder functions alphabetically
- reformat equations for better reading following guidelines
- adding comment for understanding

* Fix TLS by removing redundant BearSSL code from libmail (arendst#19472)

* Fix compilation of IRRemoteESP8266 for core3 (arendst#19473)

* Fix typo in berry mqtt (arendst#19477)

* Don't reset the MAX17043 battery fuel gauge after waking from Deep Sleep (arendst#19412)

* fix: don't reset the device when coming out of deep sleep

* fix: move debug log message to inside the device validation

* Update xsns_110_max17043.ino

* add: update global battery percentage when max17043 reports new value

* Matter events phase 1 (arendst#19484)

* Zigbee fix warnings with Arduino3 (arendst#19486)

* Fix core 2.0.12 exception

* Fix possible MQTT disconnect exception

* Tasmota ESP32 core 2.0.12 (arendst#19463)

* Matter consolidate attributes per cluster (arendst#19493)

* Improved parsing of accumulation data from HRG-15 rain sensor (arendst#19485)

* fix: more robust parsing of accumulation data

* fix: further parsing checks

* Update xdrv_29_deepsleep.ino (arendst#19492)

* Fix MAX17043 invalid JSON (arendst#19495)

* Clean up support command code

* Fix ESP8266 compilation (arendst#19485)

* Add BL0942 baudrate selection

* fix hardware serial port swap on ESP8266 (arendst#19505)

* Fix hidden invalid character

* Fix invalid character

* fix compile errors on exotic windows codepages (arendst#19508)

* Fix BL0942 higher baudrates

* Add frequency to BL0942

* ESP32 LVGL library from v8.3.8 to v8.3.9 (no functional change) (arendst#19510)

* Matter virtual lights (arendst#19511)

* Fix ESP32C3 relay click on restart

* Fix Arduino3 compilation

* Update changelogs

* Bump version v13.1.0.3

* Matter support for Virtual Devices controllable via Rules or Berry (arendst#19520)

* Fix typo

* Solidified Code updated

* Update changelogs

* fix: add command data to cmnd response (arendst#19524)

* Matter add virtual sensors (arendst#19530)

* Tasmota Core 2.0.13 (arendst#395) (arendst#19533)

Tasmota Core 2.0.13

* Fix IR compilation for ESP32 with Arduino3 (arendst#19537)

* Update RELEASENOTES.md

* Preps for IDF5.1: microphone/input for i2s audio (arendst#19544)

* fix codec compilation on IDF5.1 (arendst#19546)

* I2S improvements to MP3 play (arendst#19547)

* Fix DS18B20 for ESP32 with over 33 gpios

* Update changelogs

---------

Co-authored-by: s-hadinger <[email protected]>
Co-authored-by: Theo Arends <[email protected]>
Co-authored-by: Jason2866 <[email protected]>
Co-authored-by: Christian Baars <[email protected]>
Co-authored-by: MIzzzzon <[email protected]>
Co-authored-by: xsp1989 <[email protected]>
Co-authored-by: stefanbode <[email protected]>
Co-authored-by: gemu <[email protected]>
Co-authored-by: sfromis <[email protected]>
Co-authored-by: btsimonh <[email protected]>
Co-authored-by: s-hadinger <[email protected]>
Co-authored-by: Vincent de Groot <[email protected]>
Co-authored-by: bovirus <[email protected]>
Co-authored-by: msedv <[email protected]>
Co-authored-by: Christian Baars <[email protected]>
Co-authored-by: usr44 <[email protected]>
Co-authored-by: Paul Blacknell <[email protected]>
Co-authored-by: Дилян Палаузов <[email protected]>
Co-authored-by: SteWers <[email protected]>
Co-authored-by: paulusbrand <[email protected]>
Co-authored-by: Martin <[email protected]>
Co-authored-by: Charles <[email protected]>
Co-authored-by: Andre H. Beckedorf <[email protected]>
Co-authored-by: Barbudor <[email protected]>
Co-authored-by: Norbert Richter <[email protected]>
Co-authored-by: blakadder <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants