cryptaliagy / pixy Goto Github PK

The Pixy server is stateless beyond configuration, so deploying to kubernetes would be an easy way to scale out the service with multiple replicas.

In a multi-target scenario, not every sensor might make sense to be used for every target. If the sensor also outputs a list of tags, Pixy could match against an include/exclude list to more granularly control where messages go

Currently, I have not been able to successfully build an arm64 container in the pipeline. Some more work is required to investigate how to properly build for both amd64 & arm64 targets with a single Dockerfile

Output to InfluxDB should follow a similar pattern to the existing [pimoroni enviro[(https://github.com/pimoroni/enviro) output target to maintain compatibility for existing users

The Enviro Grow board has sensors that might not be available in the current Pixy implementation of a sensor reading. These sensor outputs and their types should be incorporated, and any sensors that are not universally shared should have their types set to an Option<T> so the models are compatible with all existing boards

Using something like minijinja, Pixy could have support for pulling environment variables into values for the targets. This would be most useful for adding things like authentication mechanisms (basic auth/bearer auth) for webhooks, as well as for credential access for future targets

After closing #11, basic auth & bearer auth can now be more safely implemented, as there is an alternative to explicitly setting this information in the configuration file.

These should be provided under an auth key for the webhook, which should support either option depending on which subkeys are used (username/password for basic auth, bearer for bearer auth).

I think it would also be a good idea to emit a warning if basic auth is used to discourage the use of it.

The Enviro Weather board has sensors that might not be available in the current Pixy implementation of a sensor reading. These sensor outputs and their types should be incorporated, and any sensors that are not universally shared should have their types set to an Option<T> so the models are compatible with all existing boards

The Enviro Urban board has sensors that might not be available in the current Pixy implementation of a sensor reading. These sensor outputs and their types should be incorporated, and any sensors that are not universally shared should have their types set to an Option<T> so the models are compatible with all existing boards

Some targets might be reserved for abnormal readings (i.e. post to Discord only if temperature > 40°C), and there should be a way to support that.

Minijinja has support for this type of feature. This should probably be integrated into the "enabled" field of each target so that an expression could be used instead

Investigation will be done for what is required for compatibility with this target, but this should (ideally) be compatible with the existing pimoroni enviro target

Support for MQTT targets should also involve some level of templating, possibly with something like minijinja to allow similar functionality to the existing one-topic-per-enviro setup that is used in the pimoroni enviro

Using MQTT is likely to provide better network performance than HTTP, which would directly translate to better battery life for devices that are being powered off of external batteries. By adding an MQTT client data source,

This could be done in 2 ways:

• Set up a separate MQTT listener output (docker container/etc)
• Add configuration options for enabling MQTT alongside the Pixy server

Since the Pixy server has a small memory footprint, I am more inclined to use the second option. This comes with the additional benefit that it allows the existing publish process to continue without having to add any variants or multiple Docker tags per version