openmotics / plugins Goto Github PK

Hi,

After upgrading to gateway version 1.17.8, I noticed input_status events were no longer processed by the MQTTClient plugin.
This seems to be related to the "version 2 decorator" that no longer works (at least for the MQTTClient plugin).

Is this a known issue? Are any other plugins affected (polysun maybe)?

Any suggestion on how to fix this? I implemented a workaround by using the version 1 decorator, but this is far from ideal.

Cheers,
David

2017-10-14 17:28:43 | Starting Astro plugin...2017-10-14 17:28:44 | Could not translate Brussels,Belgium to coordinates: OVER_QUERY_LIMIT
2017-10-14 17:28:44 | Astro is disabled

Let's see what the limit is, how we can avoid hitting it and see if we can retry if we accidently do hit the limit.

The Astro plugin is not working correctly at certain locations as it can't find out where the sun is located. The result is the plugin always reports night.

The current implementation of the plugin to work with the dewpoint tries to keep the dewpoint between certain values (target_lower and target_upper). This means that, when the humidity is too low, the ventilation will try to bring in air from the outside to increase the humidity inside.

However, when for instance in autumn or winter, the external air is much colder than the internal air, the temperature of that air will increase a lot, which will decrease the relative humidity. It might be the case that the heated external air, when reaching room temperature, has lower relative humidity than the current inside relative humidity. In that case it would have an adverse effect to take in external air.

A possible solution might be to re-calculate the relative humidity of the external air when it would be 20°C, do the same with the internal air and compare those values. When that value for the external air is higher than for the internal air, it can help to draw in external air to increase inside humidity.

Another approach to work with the dewpoint could be:

• calculate the internal dewpoint
• trigger the ventilation when the dewpoint gets too close from the measured inside temperature.
  ** For instance when calculated dewpoint is 2°C lower than measured inside temperature: ventilation to low.
  ** When 1°C lower: ventilation to medium.
  ** When less than 1°C: ventilation to high

Installation says successful but is adding in plugin list.

When looking at the plugin logs i can see the following.

{"logs": {"Astro": "2016-03-24 08:41:28.575711 - Starting Astro plugin...\n\n2016-03-24 08:41:28.683775 - Could not initialize plugin: Command 'pip install astral' returned non-zero exit status 127\nTraceback (most recent call last):\n File "/opt/openmotics/python/plugins/base.py", line 248, in _gather_plugins\n plugins.append(plugin_class(self.__webinterface, self.get_logger(name)))\n File "/opt/openmotics/python/plugins/Astro/main.py", line 50, in init\n check_output('pip install astral', shell=True)\n File "/usr/lib/python2.7/subprocess.py", line 544, in check_output\n raise CalledProcessError(retcode, cmd, output=output)\nCalledProcessError: Command 'pip install astral' returned non-zero exit status 127\n\n\n"

Works great here in combination with Home Assistant! Just tested the input messages and they work perfectly but would it be possible to add the long press info to the MQTT input event when pressing an input for more than 1 second? I have various switches that should trigger something else when holding for 3 seconds.

(on portal)
Current description: "The bit that indicates the brightest part of the day. -1 when not in use."
This is not correct. Also the name is not ideal.
Better description: "The bit that indicates when the bright_offset is reached. -1 when not in use."

Improvement for "bright_offset" description: "The offset (in minutes) after sunrise and before sunset (decided by horizon_bit) on which the bright_bit should be set."

Unable to connect to a MQTT broker because it seems to be missing a dependency after installing the 1.2.0 package

I tried to install the mqtt-client. The webpage reports a successful install, however, the plugin is not visible in the list of plugins.

Using ./logwatcher.py it seems the installation of the paho-mqtt package failed:

./logwatcher.py 10.0.1.106 MQTTClient
Password:
2016-06-11 20:17:05.708321 - Starting MQTTClient plugin...
2016-06-11 20:17:05.842911 - Could not initialize plugin: Command 'pip install paho-mqtt' returned non-zero exit status 127`

Any pointer on how to address this?

It might happen that a plugin gets an error while reading configurations. If that happens, the plugin should just re-try after a few seconds instead of thinking that there are no inputs/outputs/... configured at all.

This is currently the case for multiple plugins (including MQTTClient for which this report was initially made).

If internet connection isn't available at the time Astro request to api.sunrise-sunset.org the time of sunrise/sunset etc..., the plugin stop working. Scheduled actions are not called.

Possible solution is to cache the sunrise/sunset time points and use the old one when connection is available. Using the time points of the day before is not perfect, but acceptable: the error is of some seconds. Not working at all is really bad.

In plugins/mqtt-client, the input status topic (Default: openmotics/input/{id}/state) now publishes the following information:

{"status": "OFF", "timestamp": "2022-02-01T15:55:31.748217+00:00", "id": 36, "name": "I3Geel"}

Is it possible to know the long press information that OpenMotics supports?

Allow (optional) authentication in MQTTClient

According to the documentation, the topic openmotics/event/{id}/state publishes event status messages but when are they triggered? For my use case specifically, I have an OpenMotics automation called 'Sleep' and I'd like to know when this automation was triggered for another MQTT subscriber to do something with that information (Home Assistant in this case). Thanks in advance!

No exceptions should occur during init of a plugin. If one is raised, the plugin fails to load and won't be running/used.

Code that might fail (e.g. API calls) should be separated in a different thread that can re-try every X time. This will at least cause the plugin to start (but might be disabled), and be auto-enable once the code succeeds. Even if it's a unrecoverable issue, catching the error and logging it will allow the user to actually see the error.