Telegram bot integration

[smelis]

Hi,

Last week I bought some security cameras and was not satisfied with the capabilities of the app that came with them, so I decided to look if they used open standards and, yes, they did. I decided to look for a tool with which to connect to them and get their feeds on my PC, so I could do with them exactly what Viseron - which I did not know about - does. I then came across Viseron.

Now I have much better GPU accelerated object detection and I can record to my PC, which is way better.

And then I thought, Viseron does not offer some of the stuff the app does. Like sending notification when objects are detected. Or panning and tilting the camera. And other stuff. So, I decided to build them, and I have to say the experience has been wonderful, so far.

Apart from something weird in the devContainer when first starting it (I don't know why/what's going wrong, something with the config mount), and fighting my way through the many very strict checkers before I could commit (and later realizing, I could just skip them), development has been a breeze. The devContainer with everything ready to go is a wonderful invention.

I digress. The code:

https://github.com/smelis/viseron/tree/ptz-and-notifier

This is a work in progress. There are glaring holes, bugs and design issues. Switching cameras while patrolling? Nope. Notifier? Doesn't work anymore, because I messed it up trying to wrap my head around re-using camera configs. In any case, it's a start and should give an idea of the functionality it will eventually provide.

My ideas for further refactoring, features, fixes:

1. remove smtp notifications (make separate component, maybe, if someone wants it)
2. combine telegram notifier and telegram ptz controller in one package "telegram"
3. have ONVIF camera definitions extend AbstractCamera class and schema? (??)
4. entirely unsure if my asyncio magic is correct
5. ONVIF camera instance (+separate into class, extends AbstractCamera?) per camera instead of switching between them
6. custom Telegram keyboard for P/T/Z controls (and other commands)
7. implement recording on request
8. add stop/start camera command
9. Limit who can use the bot https://github.com/python-telegram-bot/python-telegram-bot/wiki/Frequently-requested-design-patterns#how-do-i-limit-who-can-use-my-bot
10. Can't test if zoom works
11. patrol only pans, add tilt (swing->Lissajous curves?)
12. stop patrolling on object detection
13. object tracking
14. completely unrelated, but since you're working on tiered storage: was going to build a "upload to google drive" component, but should probably be a storage tier?

I have tonnes of questions and am open to suggestions for features or otherwise.

In any case thanks for the code!

[roflcoopter]

Skimmed through the code and it looks great, really cool with the PTZ component!
Not really sure which ones are questions or if its simply a checklist, but ill answer a few of them 😊
Feel free to aks anything else that comes to mind. I am really happy to get some code contributions, have not gotten much of that yet.

2. combine telegram notifier and telegram ptz controller in one package "telegram"

It would be great if the PTZ component was decoupled from telegram and maybe exposes its functionality to other components.
That would make it easier to hook it up to something like MQTT in the future.

8. add stop/start camera command

That is available already through the MQTT component so you could do something similar to that.

14. completely unrelated, but since you're working on tiered storage: was going to build a "upload to google drive" component, but should probably be a storage tier?

Making it a storage tier is hard since the current implementation is based on listening to file system events, so that would have to change to some other approach for that to work.
But a "backup" to google drive would be cool. Maybe a way to export certain recordings from the UI to the cloud as well?

PS: If you want to open a PR with your changes it would be easier for me to give some comments on your code and see if there are better ways to do things. I am impressed you have figured out so much on your own since the developer docs are not great yet!

[roflcoopter]

You could listen to the event EVENT_RECORDER_COMPLETE which gets fired when the recordings concatenation finishes (Which only gets fired if you have create_event_clip: true for your recorder config.
That way you dont have to listen to all state changes and filter out the ones that matter

[smelis]

Got it and it works :)

[smelis]

Thanks for getting back to me! I have to say I've been having a lot of fun developing. You must have invested a lot of time getting this to where it is. It's really impressive. The choice for the devContainer setup is excellent and the code, though complicated, is a delight to work with. Having the devContainer up and running with all the tools exactly right meant I could just set a breakpoint and start figuring stuff out within a couple hours. This makes up a lot for not having developer docs yet.

I'm often tempted by open source software to dive in and hack my desired features into it, only to then be daunted by a week of "what the frick"-filled nights trying to get the development environment and pipeline running, after which I lose interest and have probably been tempted by something else.

The only issue I had was with the /config mount point. I'm not sure why it fails for me. When I remove it, the devContainer builds without issue and purs like a kitten. Not having the config in the repo works fine for me. Let me know if I can test something for you there.

When I re-enable the mount and rebuild the devContainer I get this error:

This is the salient bit from the logs I see when I go into the recovery container:

[2024-07-27T19:13:31.640Z] Start: Starting container
[2024-07-27T19:13:31.640Z] Start: Run: docker run --sig-proxy=false -a STDOUT -a STDERR --mount source=/workspaces/viseron/config,target=/config,type=bind,consistency=cached --mount type=volume,src=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047,dst=/workspaces --mount type=volume,src=vscode,dst=/vscode -l vsch.local.repository=https://github.com/smelis/viseron/ -l vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 -l vsch.local.repository.folder=viseron -l devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json -e DEVCONTAINER=1 -e PUID=1000 -e PGID=1000 -u root -e GIT_EDITOR=code --wait --entrypoint /bin/sh vsc-viseron-d5e808acdb1a21446d1389dd2513f87759d110823623e0e20f725547b6b46610 -c echo Container started
[2024-07-27T19:13:31.649Z] docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /workspaces/viseron/config.
See 'docker run --help'.
[2024-07-27T19:13:31.650Z] Stop (10 ms): Run: docker run --sig-proxy=false -a STDOUT -a STDERR --mount source=/workspaces/viseron/config,target=/config,type=bind,consistency=cached --mount type=volume,src=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047,dst=/workspaces --mount type=volume,src=vscode,dst=/vscode -l vsch.local.repository=https://github.com/smelis/viseron/ -l vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 -l vsch.local.repository.folder=viseron -l devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json -e DEVCONTAINER=1 -e PUID=1000 -e PGID=1000 -u root -e GIT_EDITOR=code --wait --entrypoint /bin/sh vsc-viseron-d5e808acdb1a21446d1389dd2513f87759d110823623e0e20f725547b6b46610 -c echo Container started
[2024-07-27T19:13:31.650Z] Start: Run: docker ps -q -a --filter label=vsch.local.repository=https://github.com/smelis/viseron/ --filter label=vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 --filter label=vsch.local.repository.folder=viseron --filter label=devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json
[2024-07-27T19:13:31.652Z] Stop (13 ms): Run: docker events --format {{json .}} --filter event=start
[2024-07-27T19:13:31.658Z] Stop (8 ms): Run: docker ps -q -a --filter label=vsch.local.repository=https://github.com/smelis/viseron/ --filter label=vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 --filter label=vsch.local.repository.folder=viseron --filter label=devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json
[2024-07-27T19:13:31.659Z] Error: Command failed: docker run --sig-proxy=false -a STDOUT -a STDERR --mount source=/workspaces/viseron/config,target=/config,type=bind,consistency=cached --mount type=volume,src=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047,dst=/workspaces --mount type=volume,src=vscode,dst=/vscode -l vsch.local.repository=https://github.com/smelis/viseron/ -l vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 -l vsch.local.repository.folder=viseron -l devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json -e DEVCONTAINER=1 -e PUID=1000 -e PGID=1000 -u root -e GIT_EDITOR=code --wait --entrypoint /bin/sh vsc-viseron-d5e808acdb1a21446d1389dd2513f87759d110823623e0e20f725547b6b46610 -c echo Container started
[2024-07-27T19:13:31.659Z] trap "exit 0" 15
[2024-07-27T19:13:31.659Z] exec "$@"
[2024-07-27T19:13:31.659Z] while sleep 1 & wait $!; do :; done - /init
[2024-07-27T19:13:31.659Z]     at ptA (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:465:1260)
[2024-07-27T19:13:31.659Z]     at NH (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:465:1002)
[2024-07-27T19:13:31.659Z]     at processTicksAndRejections (node:internal/process/task_queues:96:5)
[2024-07-27T19:13:31.659Z]     at async KtA (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:482:3771)
[2024-07-27T19:13:31.659Z]     at async eB (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:482:4886)
[2024-07-27T19:13:31.659Z]     at async hrA (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:663:200)
[2024-07-27T19:13:31.659Z]     at async lrA (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:662:13452)
[2024-07-27T19:13:31.663Z] Stop (3085 ms): Run in container: node /root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js up --container-session-data-folder /tmp/devcontainers-243eeb20-b1e7-4ee4-94a0-2a1d672eea441722107607167 --workspace-folder /workspaces/viseron --workspace-mount-consistency cached --id-label vsch.local.repository=https://github.com/smelis/viseron/ --id-label vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 --id-label vsch.local.repository.folder=viseron --id-label devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json --log-level debug --log-format json --config /workspaces/viseron/.devcontainer/devcontainer.json --override-config /tmp/devcontainer-1d6a9f3f-58f1-48e4-8c6c-aa5e9c6c4a18.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047,target=/workspaces,external=true --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default off --mount-workspace-git-root --include-configuration --include-merged-configuration
[2024-07-27T19:13:31.663Z] Exit code 1
[2024-07-27T19:13:31.663Z] Start: Run: docker rm -f 1ad021bf52488d3af5a1e10e46af89e7d7c9d9853bbfd63ea1332d1baac6025b
[2024-07-27T19:13:31.667Z] Command failed: node /root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js up --container-session-data-folder /tmp/devcontainers-243eeb20-b1e7-4ee4-94a0-2a1d672eea441722107607167 --workspace-folder /workspaces/viseron --workspace-mount-consistency cached --id-label vsch.local.repository=https://github.com/smelis/viseron/ --id-label vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 --id-label vsch.local.repository.folder=viseron --id-label devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json --log-level debug --log-format json --config /workspaces/viseron/.devcontainer/devcontainer.json --override-config /tmp/devcontainer-1d6a9f3f-58f1-48e4-8c6c-aa5e9c6c4a18.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047,target=/workspaces,external=true --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default off --mount-workspace-git-root --include-configuration --include-merged-configuration
[2024-07-27T19:13:31.667Z] Exit code 1
[2024-07-27T19:13:31.676Z] Stop (3694 ms): Run in container: /bin/sh
[2024-07-27T19:13:31.678Z] Stop (3632 ms): Run in container: /bin/sh
[2024-07-27T19:13:31.678Z] Container server terminated (code: 137, signal: null).

Remove the mount point, rebuild, and poof I have a working environment again.

About issues. There was one more. When I came around to committing my code - I am unfamiliar with VS Code, so I thought I'd try the builtin interface iso the command line - the commit would just hang forever. After a couple of what the fricks I found that it was due to tests failing and that using git from the terminal does work and outputs the test results. Anyway, this might be worth mentioning in the developer documentation.

Another thing you could mention, for slower people like me, is that though your tests are strict and they need to pass the pre-commit hook, you don't have to necessarily perform them before you commit to your own branch on your own fork. I had about an hour of going "why are these checks so strict!? I just want to push my code for safe keeping and versioning!" before I thought "hold up, there's probably a way to skip them". That being said, I have kept it enabled on every commit, because it's forcing me to be more thoughtful of my code.

The developer docs could also make note of how to mitigate the various checks/tests/linters' oft reported problems or provide links to their documentation for clarification or mitigation. E.g. I'm unfamiliar with the various checkers' reports so knowing you can do

io_buf = io.BytesIO(buffer)  # type: ignore[arg-type]

from the dev-docs would be nice. Or what the guidelines are for including stuff in .mypy.ini:

[mypy-telegram-ext.*]
ignore_missing_imports = True

I can't imagine you've setup all these tests just to have them by passed :D

Now, as for you answers.

Decoupling PTZ from Telegram sounds like a good idea. Having PTZ in the UI would be awesome, but developing for the UI is a bit daunting at this point. I'd rather spend some time familiarizing myself with the python code first. Like, how do I decouple these things and have them consumable from both the UI and a Telegram component in a way that makes sense? Any code I could look at to get an idea?

I will have a look at that library of notifiers and see if I can integrate it. For now I've taken out the SMTP notifier. Maybe I'll create an AbstractNotifier and override a couple implementations that make sense.

While browsing the code I did already find the create_event_clip: true config setting and I get the clips now and they get sent straight to my phone :D

I do also get some errors with regard to a clip_init.mp4 file that can't be found by the fragmenter in the segments folder. I'm not sure if that started when I enabled the create_event_clip, but I can imagine it does. I had been looking into that, but at that point it was 07:00 and I was starting to fall asleep.

Waiting for a single EVENT_RECORDER_COMPLETE event sounds like it's more efficient going through all the state changes. I will look into that.

I'd read in one of the issues or discussions that you'd implement start/stop in MQTT already, so was looking into that too, but was having some difficulty understanding how I should implement it. Specifically how to get an instance of the Camera (?) object that implements the turn_on() and turn_off() methods. I've not looked into this much, yet. If you could point it out it would save me some time.

I'll put "backup to cloud" on my list too because I'd really like to have that feature myself.

I'll open a PR for this. Just wanted to make sure first you'd be open to accepting it :)

One last question. How would I go about getting my devContainer to run with CUDA enabled? Is it as simple as changing the devContainer's base image?

[roflcoopter]

Thanks for getting back to me! I have to say I've been having a lot of fun developing. You must have invested a lot of time getting this to where it is. It's really impressive. The choice for the devContainer setup is excellent and the code, though complicated, is a delight to work with. Having the devContainer up and running with all the tools exactly right meant I could just set a breakpoint and start figuring stuff out within a couple hours. This makes up a lot for not having developer docs yet.

I'm often tempted by open source software to dive in and hack my desired features into it, only to then be daunted by a week of "what the frick"-filled nights trying to get the development environment and pipeline running, after which I lose interest and have probably been tempted by something else.

The only issue I had was with the /config mount point. I'm not sure why it fails for me. When I remove it, the devContainer builds without issue and purs like a kitten. Not having the config in the repo works fine for me. Let me know if I can test something for you there.

When I re-enable the mount and rebuild the devContainer I get this error:

This is the salient bit from the logs I see when I go into the recovery container:

[2024-07-27T19:13:31.640Z] Start: Starting container
[2024-07-27T19:13:31.640Z] Start: Run: docker run --sig-proxy=false -a STDOUT -a STDERR --mount source=/workspaces/viseron/config,target=/config,type=bind,consistency=cached --mount type=volume,src=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047,dst=/workspaces --mount type=volume,src=vscode,dst=/vscode -l vsch.local.repository=https://github.com/smelis/viseron/ -l vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 -l vsch.local.repository.folder=viseron -l devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json -e DEVCONTAINER=1 -e PUID=1000 -e PGID=1000 -u root -e GIT_EDITOR=code --wait --entrypoint /bin/sh vsc-viseron-d5e808acdb1a21446d1389dd2513f87759d110823623e0e20f725547b6b46610 -c echo Container started
[2024-07-27T19:13:31.649Z] docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /workspaces/viseron/config.
See 'docker run --help'.
[2024-07-27T19:13:31.650Z] Stop (10 ms): Run: docker run --sig-proxy=false -a STDOUT -a STDERR --mount source=/workspaces/viseron/config,target=/config,type=bind,consistency=cached --mount type=volume,src=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047,dst=/workspaces --mount type=volume,src=vscode,dst=/vscode -l vsch.local.repository=https://github.com/smelis/viseron/ -l vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 -l vsch.local.repository.folder=viseron -l devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json -e DEVCONTAINER=1 -e PUID=1000 -e PGID=1000 -u root -e GIT_EDITOR=code --wait --entrypoint /bin/sh vsc-viseron-d5e808acdb1a21446d1389dd2513f87759d110823623e0e20f725547b6b46610 -c echo Container started
[2024-07-27T19:13:31.650Z] Start: Run: docker ps -q -a --filter label=vsch.local.repository=https://github.com/smelis/viseron/ --filter label=vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 --filter label=vsch.local.repository.folder=viseron --filter label=devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json
[2024-07-27T19:13:31.652Z] Stop (13 ms): Run: docker events --format {{json .}} --filter event=start
[2024-07-27T19:13:31.658Z] Stop (8 ms): Run: docker ps -q -a --filter label=vsch.local.repository=https://github.com/smelis/viseron/ --filter label=vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 --filter label=vsch.local.repository.folder=viseron --filter label=devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json
[2024-07-27T19:13:31.659Z] Error: Command failed: docker run --sig-proxy=false -a STDOUT -a STDERR --mount source=/workspaces/viseron/config,target=/config,type=bind,consistency=cached --mount type=volume,src=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047,dst=/workspaces --mount type=volume,src=vscode,dst=/vscode -l vsch.local.repository=https://github.com/smelis/viseron/ -l vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 -l vsch.local.repository.folder=viseron -l devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json -e DEVCONTAINER=1 -e PUID=1000 -e PGID=1000 -u root -e GIT_EDITOR=code --wait --entrypoint /bin/sh vsc-viseron-d5e808acdb1a21446d1389dd2513f87759d110823623e0e20f725547b6b46610 -c echo Container started
[2024-07-27T19:13:31.659Z] trap "exit 0" 15
[2024-07-27T19:13:31.659Z] exec "$@"
[2024-07-27T19:13:31.659Z] while sleep 1 & wait $!; do :; done - /init
[2024-07-27T19:13:31.659Z]     at ptA (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:465:1260)
[2024-07-27T19:13:31.659Z]     at NH (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:465:1002)
[2024-07-27T19:13:31.659Z]     at processTicksAndRejections (node:internal/process/task_queues:96:5)
[2024-07-27T19:13:31.659Z]     at async KtA (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:482:3771)
[2024-07-27T19:13:31.659Z]     at async eB (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:482:4886)
[2024-07-27T19:13:31.659Z]     at async hrA (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:663:200)
[2024-07-27T19:13:31.659Z]     at async lrA (/root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js:662:13452)
[2024-07-27T19:13:31.663Z] Stop (3085 ms): Run in container: node /root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js up --container-session-data-folder /tmp/devcontainers-243eeb20-b1e7-4ee4-94a0-2a1d672eea441722107607167 --workspace-folder /workspaces/viseron --workspace-mount-consistency cached --id-label vsch.local.repository=https://github.com/smelis/viseron/ --id-label vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 --id-label vsch.local.repository.folder=viseron --id-label devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json --log-level debug --log-format json --config /workspaces/viseron/.devcontainer/devcontainer.json --override-config /tmp/devcontainer-1d6a9f3f-58f1-48e4-8c6c-aa5e9c6c4a18.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047,target=/workspaces,external=true --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default off --mount-workspace-git-root --include-configuration --include-merged-configuration
[2024-07-27T19:13:31.663Z] Exit code 1
[2024-07-27T19:13:31.663Z] Start: Run: docker rm -f 1ad021bf52488d3af5a1e10e46af89e7d7c9d9853bbfd63ea1332d1baac6025b
[2024-07-27T19:13:31.667Z] Command failed: node /root/.vscode-remote-containers/dist/dev-containers-cli-0.375.1/dist/spec-node/devContainersSpecCLI.js up --container-session-data-folder /tmp/devcontainers-243eeb20-b1e7-4ee4-94a0-2a1d672eea441722107607167 --workspace-folder /workspaces/viseron --workspace-mount-consistency cached --id-label vsch.local.repository=https://github.com/smelis/viseron/ --id-label vsch.local.repository.volume=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047 --id-label vsch.local.repository.folder=viseron --id-label devcontainer.config_file=/workspaces/viseron/.devcontainer/devcontainer.json --log-level debug --log-format json --config /workspaces/viseron/.devcontainer/devcontainer.json --override-config /tmp/devcontainer-1d6a9f3f-58f1-48e4-8c6c-aa5e9c6c4a18.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=viseron-b45258b996bf3899b0ed3c16f05948d8e023b0534dcfa67b685d160c1885b047,target=/workspaces,external=true --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default off --mount-workspace-git-root --include-configuration --include-merged-configuration
[2024-07-27T19:13:31.667Z] Exit code 1
[2024-07-27T19:13:31.676Z] Stop (3694 ms): Run in container: /bin/sh
[2024-07-27T19:13:31.678Z] Stop (3632 ms): Run in container: /bin/sh
[2024-07-27T19:13:31.678Z] Container server terminated (code: 137, signal: null).

Remove the mount point, rebuild, and poof I have a working environment again.

Yes i have spent countless of hours on this project!
I did not know anything about Python, Docker or React when i started so its been a learning experience for sure.
The /config mount failure is probably simply because the folder does not exist in your repo folder. Will try to get that fixed.

About issues. There was one more. When I came around to committing my code - I am unfamiliar with VS Code, so I thought I'd try the builtin interface iso the command line - the commit would just hang forever. After a couple of what the fricks I found that it was due to tests failing and that using git from the terminal does work and outputs the test results. Anyway, this might be worth mentioning in the developer documentation.

Another thing you could mention, for slower people like me, is that though your tests are strict and they need to pass the pre-commit hook, you don't have to necessarily perform them before you commit to your own branch on your own fork. I had about an hour of going "why are these checks so strict!? I just want to push my code for safe keeping and versioning!" before I thought "hold up, there's probably a way to skip them". That being said, I have kept it enabled on every commit, because it's forcing me to be more thoughtful of my code.

The developer docs could also make note of how to mitigate the various checks/tests/linters' oft reported problems or provide links to their documentation for clarification or mitigation. E.g. I'm unfamiliar with the various checkers' reports so knowing you can do

io_buf = io.BytesIO(buffer)  # type: ignore[arg-type]

from the dev-docs would be nice. Or what the guidelines are for including stuff in .mypy.ini:

[mypy-telegram-ext.*]
ignore_missing_imports = True

I can't imagine you've setup all these tests just to have them by passed :D

I will consider disabling the checks by default, i agree that it might be a bit frustrating if you dont know whats going on.
Will improve the docs on this point.
FYI you can remove the commit checks locally by running the command pre-commit uninstall

I'd read in one of the issues or discussions that you'd implement start/stop in MQTT already, so was looking into that too, but was having some difficulty understanding how I should implement it. Specifically how to get an instance of the Camera (?) object that implements the turn_on() and turn_off() methods. I've not looked into this much, yet. If you could point it out it would save me some time.

You can use the method get_registered_domain on the Viseron object to get a specific camera instance (or any domain instance for that matter like object detecotrs, motion detectors etc)

Here is an example:

viseron/viseron/domains/object_detector/zone.py

Line 46 in 2d73366

self._camera = vis.get_registered_domain(CAMERA_DOMAIN, camera_identifier)

One last question. How would I go about getting my devContainer to run with CUDA enabled? Is it as simple as changing the devContainer's base image?

Actually no idea how to do that, my dev machine does not have a GPU, only my "production" server does so i have not looked into that.

Thank you for your time and feedback!

[smelis]

Yes i have spent countless of hours on this project!

Thanks for that!

I will consider disabling the checks by default, i agree that it might be a bit frustrating if you dont know whats going on.
Will improve the docs on this point.
FYI you can remove the commit checks locally by running the command pre-commit uninstall

I'm leaving them on as I don't want to get hit with 1000 mypy errors when i get to merging this :)

I've refactored the code so that PTZ and Telegram are decoubled and created a PR for it.
Hidden in the commits is also a fix for the EVENT_RECORDER_COMPLETE event. It was fired by the framework without format()ing, so it just had '{camera_identifier}/event/record/complete' iso 'camera_1/event/recorder/complete' (or whateve the event is called).

[roflcoopter]

I'm leaving them on as I don't want to get hit with 1000 mypy errors when i get to merging this :)

Yes that is probably wise :D They can be annoying but they do help catch bugs and keep a consistent code base.

I've refactored the code so that PTZ and Telegram are decoubled and created a PR for it.
Hidden in the commits is also a fix for the EVENT_RECORDER_COMPLETE event. It was fired by the framework without format()ing, so it just had '{camera_identifier}/event/record/complete' iso 'camera_1/event/recorder/complete' (or whateve the event is called).

Nice, thanks for fixing that

[smelis]

Yeah, you're right. It's annoying at first, but it is catching a lot of bugs. And now that I'm checking regularly and getting used to what type of fix goes with what type of error, it's not that bad.

[smelis]

This is where the fragmenter fails, btw. I tried skipping clip_init.mp4 in here and it "solved" the problem (i.e. made the error go away), but I can't imagine it's a proper fix.

def _get_mp4_files_to_fragment(path: str) -> list[str]:
    """Get mp4 files that are not in use by ffmpeg/gstreamer."""
    mp4_files = Path(path).walkfiles("*.mp4")
    files_in_use = []
    for process in psutil.process_iter():
        try:
            process_name = process.name()
            if any(pattern in process_name for pattern in ["ffmpeg", "gstreamer"]):
                files_in_use.extend(_get_open_files(path, process))
        except psutil.Error:
            pass
    return [str(f.name) for f in mp4_files if str(f.name) not in files_in_use]

[roflcoopter]

What is the error message specifically?
create_event_clip should not affect this part if im not mistaken

[smelis]

I don't seem to get it anymore. Will keep an eye on it.