Feature/sensors

[orangecms]

• Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

• Bug fix
• Feature implementation
• Doc updates

• What changes have you introduced?

#611, #432

• Does this PR introduce a breaking change?

no

• Preview / Steps to verify your work:

[orangecms]

The main part is done now. Feedback would be great. :)

The Codacy feedback is a bit surprising. Both prettier and eslint are fine with the current state.

[bessman]

The Python code looks fine, can't comment on JS.

[mariobehling]

Lets move forward and follow up on Codacy later. Merging this therefore. Well-done!

[mariobehling]

@orangecms Usually we ask contributors to fork the repository and work in their own fork and then make a PR to the repo. One reason is that we had a lot of abandoned branches in the past and it became more and more difficult to keep track of PRs. People come and go and some people make a PR and dont follow up on change requests. This kind of policy helped us to stay focused. Thanks

[orangecms]

Okay cool, will do from now on.

How is release engineering handled? With a new feature, a minor bump would make sense, right? That would be great for distributions so they can pick up the release from a tag and upgrade packages. I can take care of that if that's okay.

[mariobehling]

That would be awesome. Thank you!