Describe the bug
The GetAll endpoint always returns an empty array. When getting all keys, nothing is returned.

To Reproduce
Steps to reproduce the behaviour:

1. Make a GET request for the device root endpoint
2. See empty array as response. Should be HTTP200

Expected behaviour
All devices dhould be returned

Describe what you would like to change
Allow a user to post to the search endpoint and use any field within the device dto as search criteria. We should search by all populated fields. We should show results based on any fields containing search criteria.

Describe your issue with existing functionality
We currently use query string and it boats the controller

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
The status field currently returns null. It should return something like "OK", or messages related to failures or certain conditions.

Describe the solution you'd like
A set of rules should be sent to an endpoint to define rules in which to show "OK" or another status message depending on if certain conditions are met.

Condition examples

• No ping for x minutes
• Service is not running
• IP address has changed
• Battery level is under threshold

Additional context
We should send JSON to an endpoint to define these rules. They should stay on the server until new ones are updated or they no longer exist. If no rules exist, the status field will still return null

Describe what you would like to change
Add a new model for docker container and show information such as:

• uptime-
• port
• docker image
• docker container name
• any volumes associated.

Describe your issue with existing functionality
At the moment the services list is a bit basic. Any docker containers have some very specific attributes like port, image name and uptime.

Additional context
We might need to remove the current services list or maybe rename it to something like BasicServices

Is your feature request related to a problem? Please describe.
This should increase quality on CI builds

Describe the solution you'd like
When CI builds, we should be able to lint any ansible playbooks. We can then see issues

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.

The current Prometheus API endpoint does not provide information on devices, their battery level, IP address, and custom attributes, which can be crucial information for system administrators and developers to monitor and troubleshoot the system.

Describe the solution you'd like

To address this issue, we propose adding a new API endpoint to Prometheus that provides information on devices, including their battery level, IP address, and custom attributes. The new endpoint would be designed to return data in a format that is easy to parse and consume by other tools and systems.

Additional context

Adding this endpoint would provide valuable information for system administrators and developers to monitor and troubleshoot their systems, and would make Prometheus a more versatile and useful tool for monitoring and managing distributed systems.

Is your feature request related to a problem? Please describe.
When pulling docker images, it is a manual process. Instead we should be able to pull a docker image when we would like to run the API on produciton or dev environment

Describe the solution you'd like
When we merge into deployment branch, then we publish the docker image to githubs registry

Describe alternatives you've considered
N/A

Additional context
Use this link here: https://docs.github.com/en/actions/publishing-packages/publishing-docker-images

Describe what you would like to change
Use a Dictionary<string, string> to contain an attribute name and a payload. At the moment we only care about string values. If we need objects then we can extend later.

Describe your issue with existing functionality
There are some strongly typed objects which could do with being more generic.

Additional context
We should be able to search by attribute name using regex or wildcards.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe what you would like to change
There is a plan to introduce other services which may pre-populate discovered devices using nmap. However these should not be counted as 'checkins' as they are not from the source device. So we should have a modified date and a last checkin date which is a ping from the device itself.

Describe your issue with existing functionality
The modified date will be updated if there are any changes to the device checkin state. But this might not be from the device itself. We want to separate the two.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe what you would like to change
Currently all repository methods are not async. This was done to get the project up and running. Now we should use async to help reduce load times to data sources and to allow more requests to be run concurrently. This should hopefully see a small performance increase but also means that we are not locking endpoints waiting for each request to finish.

Describe your issue with existing functionality
Nothing as the project is small, but in time this will be an issue when more endpoints call the service.

Additional context
Using local memory storage might be questionable. Unsure if they will work with async.

Describe what you would like to change
I would like to submit to discord webhooks when certain services are down or other criteria has been met

Describe your issue with existing functionality
At the moment there is no functionality with webhooks

Additional context

• This should be enabled or disabled via function flag
• Users should use the appsettings to set up webhook URLs

Is your feature request related to a problem? Please describe.
New feature to reduce the amount of data sent back in a request

Describe the solution you'd like
Summary should only contain specific fields. We don't need to bring back any metadata. We should return at least these fields:

• Name
• IP Address
• Available services. We only need to list the services, we don't need associated metadata)
• Battery levels and power type (AC or battery)
• Last heartbeat time (x

Describe alternatives you've considered
No alternative known

Additional context
If we need any metadata like IDs, created/modified dates then we should use an endpoint for a specific device http://x.x.x.x:0000/device?name=laptop

Is your feature request related to a problem? Please describe.

The current API endpoint does not allow users to define their own predicates, sorting, and pagination, which can be limiting for users who require more control over the data they receive. Additionally, the API returns all available data, regardless of whether it is relevant to the client, which can result in excessive network usage and slower performance.

Describe the solution you'd like

To address this issue, we propose using GraphQL to allow users to define their own predicates, sorting, and pagination. The GraphQL schema would be designed to allow users to specify the exact data they need and the format in which it should be returned.

Additionally, we propose using GraphQL to only return data that is relevant to the client. This can be achieved through a combination of filtering and authentication mechanisms. Users would be required to authenticate with the system and provide their credentials, which would then be used to determine which data is relevant to them.

Describe alternatives you've considered

An alternative approach would be to use a more traditional REST API and provide users with a set of query parameters for filtering, sorting, and pagination. However, this approach can become unwieldy and difficult to manage as the number of parameters increases. Additionally, it would still require users to receive all available data, which may not be relevant to them.

Additional context

Implementing this feature would provide users with a more flexible and efficient way to retrieve data from the API. Additionally, it would make it easier for developers to build custom applications and integrations on top of the API.

Describe what you would like to change
We want to enhance the current system's functionality by allowing Docker Compose to pass environment variables specifically related to Redis URL into our .NET application. Our .NET application currently uses an appsettings.json file for configuration settings.

In this enhancement, the Docker Compose YAML file will be updated to include the Redis URL as an environment variable, which can then be accessed within the .NET application. This change will make the application more dynamic and flexible, as we can adjust the Redis URL without modifying the .NET application's code or appsettings.json file directly.

Describe your issue with existing functionality
The current issue with the existing functionality is that the Redis URL is hard-coded into the appsettings.json file. This approach is not ideal when we want to use different Redis instances (like in dev/test/prod environments) or when we need to change the Redis URL, as it requires a change in the application code and re-deployment.

Allowing Docker Compose to pass the Redis URL as an environment variable will make it easier to switch between different environments or update the Redis URL without modifying the .NET application's code directly. This enhancement is particularly beneficial for maintaining consistency across different environments and streamlining deployments.

Screenshots
Not applicable for this change as it relates to configuration and code changes.

Additional context
Here's an example of what the Docker Compose file might look like after the change:

version: '3'
services:
  your-dotnet-service:
    image: your-dotnet-image
    environment:
      - Redis__ConnectionStrings__Default=your-redis-url

And in your .NET application, you can access this environment variable using the Configuration API:

string redisUrl = Configuration.GetConnectionString("Default");

Remember to configure the Configuration object to read from environment variables. This change will provide us with more flexibility, better environment isolation, and a streamlined deployment process. The exact implementation might differ based on your specific use case and application structure.

Describe the bug
The pipeline builds are failing after upgrading to net7. Suspect is the pipeline yaml files. Docker files should already be updated.

To Reproduce
Steps to reproduce the behaviour:

1. Run build action

Expected behaviour
No build errors

Is your feature request related to a problem? Please describe.
This is a feature to keep track of Syncthing and what devices are connected to what. We are trying to determine if the mesh is working.

Describe the solution you'd like
To see what devices another device is connected to and if all connections have been talking to each other properly. We can then determine bottlenecks.

Describe what you would like to change

• Move PowerType into it's own enum file
• Update DevicePower.Type to use the PowerType enum
• Update device summary to show the power type
  • If the power type is BATTERY, then show the battery percentage

Describe your issue with existing functionality
The power Type could be anything. We need to use an Enum so we can apply custom mappings to show batter level when needed