As soon as a new build on the master/main branch was done, it would be great to automatically create a release and update the artifact for the installer also automatically.

Right now nearly every part of the code is in the program.cs. This was used for fast debugging but should be fixed before implementing further features.

Is your feature request related to a problem? Please describe.
Because of the ARM6 Architecture of the Raspberry Pi zero it is not possible to run the DeviceClient .net core code. So we need to think about alternatives.

Describe the solution you'd like
It would like to get the same experience from the normal DeviceClient on the RaspberryPi zero. So we may need to rewrite the deviceclient.

Describe alternatives you've considered
Alternatively we could consider to work with the mono framework and check how we have to rewrite the stuff to be compliant with the mono framework and its dependencies.

The code to send the 433MhZ signals is still missing and needs to be added.

Create a Documentation and a getting started guide.

Describe the bug
I noticed that the Device Client Code unfortunately is crashing after a while.
We need to mitigate this and figure out how to resolve this.

To Reproduce
Steps to reproduce the behavior:

1. Start Device Client
2. Run Device Client for x hours (x need to be determined)
3. Device Code crashes

Expected behavior
Device is running unless job is stopped.

Screenshots
Will follow up.

Hardware (please complete the following information):

• Device: Raspberry Pi 3
• OS: Linux raspberrypi 4.19.118-v7+
• App Version: 1.5

Is your feature request related to a problem? Please describe.
In the current state the application ca be run via screen on linux in order to have it run in the background. However the whole setup has its issues, if the process fails you wont notice it and it cannot restart automatically.

Describe the solution you'd like
It would be great if there could be a systemd integration so that we can tell systemd to always restart it on failure and have it started in the background after the system boots.

Describe alternatives you've considered
Other implementations could be done via Docker but Docker is not running without problems on every IoT Device.

Describe the solution you'd like
Right now the solution uses 433utils (codesend) written in C in order to send the 433MHz signals.
It would be better if the code used to send the signals would be written in C# and part of this project as well.

Additional context
Might wanna consider to use somethin like Panzenbaby/Raspberry-Remote-for-Windows-10-IoT-Core

Is your feature request related to a problem? Please describe.
It has been a while since the project got updated and I need to update dependencies, framework and maybe even business logic to stay current.

Describe the solution you'd like
An updated version with the latest security updates and an LTS Version of .NET.

In order to automate the build and make the deployment more easier it would be good to implement a Docker Build GitHub Action.

Describe the solution you'd like
In order to stay up to date with the .NET project we will need to consider an update to .NET5.

Describe the solution you'd like
It would be great if the Device could switch to offline/not ready state if it fails to send keepalive
requests to IoT Central. If implemented we could trigger alerts from IoT Central to notify admins that their devices are offline.

Describe alternatives you've considered
Device is sending status messages every n minute (where n can be configured in the settings).
We would need a solution (like an Azure Function) which will check for the latest updates. If the latest update is gone longer than n*2 we should switch the device to offline, so that IoT Central notices and will execute the aligned action rules.

Describe the bug
Even though the Function solution is containing two Functions, only one will be deployed.
We need to check why the other function is not deployed correctly.

Is your feature request related to a problem? Please describe.
Right now the update interval and the door cooldown time are hardcoded.

Describe the solution you'd like
It would be better if we could se the settings per device from Azure IoT Central

Describe alternatives you've considered
As an alternative we might be able to implement a setting in the config as well.

Describe the bug
When working with multiple devices in parallel and multiple requests are send to the Pi, he will execute the 433MHz sending multiple times as well. In a bad case your car get smashed because the door you just opened will close immediately again.

To Reproduce
Steps to reproduce the behavior:

1. Send one request from DeviceA for a specific door
2. Send a request from another Device for the same door
3. Door will open and close immediately again

Expected behavior
When a door command is triggerd there should be a cooldown limit until the next command will be processed.

Hardware (please complete the following information):

• Device: Raspberry Pi 3
• OS: Raspbian
• App Version 1.4

It would be good if the doors could be registered from IoT Central. Think about adding a Cloud Property for it.

Describe the solution you'd like
It would be good to have a shell script which will download the latest app version, setup the systemd service and start the application. Should work like a „one click installer“ using bash.

It would be great if we could leverage IP Cameras and use their feed to feed an AI to determine whether the door is open or not since 433MhZ is stateless.

You also could implement rules like "make sure door is closed after 10 pm" or always send close signal after door is open for amount x of time.