timeout beim stop

[whe]

kann es sein, dass das plugin SMA_EM das gleiche problem hat beim stop ?
heute habe ich das mal auf dem pi3 aktiviert; daraufhin verhält sich smarthome.py --stop genau so.

[whe]

Hier nochmal das Problem im debug modus:
auch das PlugIn: sma-em führt zu dem Fehler:

^C2017-10-20 15:38:12 INFO     smarthome    Main         Number of Threads: 17 -- smarthome.py:stop:371
2017-10-20 15:38:12 INFO     plugin       Main         Stop Plugins -- plugin.py:stop:108
2017-10-20 15:38:12 DEBUG    plugin       Main         Stopping BackendServer Plugin -- plugin.py:stop:110
2017-10-20 15:38:12 DEBUG    __init__     Main         BackendServer: shutting down -- __init__.py:stop:162
2017-10-20 15:38:12 INFO     _cplogging   Main         [20/Oct/2017:15:38:12] ENGINE HTTP Server cherrypy._cpwsgi_server.CPWSGIServer(('192.168.178.41', 8383)) shut down -- _cplogging.py:error:219
2017-10-20 15:38:12 DEBUG    __init__     Main         BackendServer: engine exited -- __init__.py:stop:165
2017-10-20 15:38:12 DEBUG    plugin       Main         Stopping knx Plugin -- plugin.py:stop:110
2017-10-20 15:38:12 DEBUG    plugin       Main         Stopping visu Plugin -- plugin.py:stop:110
2017-10-20 15:38:12 DEBUG    connection   Main         websockethandler: closing socket 192.168.178.21:51870 -- connection.py:close:310
2017-10-20 15:38:12 DEBUG    plugin       Main         Stopping smartvisu Plugin -- plugin.py:stop:110
2017-10-20 15:38:12 DEBUG    plugin       Main         Stopping sql Plugin -- plugin.py:stop:110
2017-10-20 15:38:12 DEBUG    plugin       Main         Stopping simulation Plugin -- plugin.py:stop:110
2017-10-20 15:38:12 INFO     __init__     Main         Exit Simulation -- __init__.py:stop:63
2017-10-20 15:38:12 DEBUG    plugin       Main         Stopping sma_em Plugin -- plugin.py:stop:110
2017-10-20 15:38:12 DEBUG    connection   Main         KNX: closing socket 127.0.0.1:6720 -- connection.py:close:310
2017-10-20 15:38:14 INFO     smarthome    Main         Thread: sma_em, still alive -- smarthome.py:stop:393
2017-10-20 15:38:14 INFO     smarthome    Main         Thread: Main, still alive -- smarthome.py:stop:393

^C2017-10-20 15:38:32 INFO     smarthome    Main         Number of Threads: 2 -- smarthome.py:stop:371
2017-10-20 15:38:32 INFO     plugin       Main         Stop Plugins -- plugin.py:stop:108
2017-10-20 15:38:32 DEBUG    plugin       Main         Stopping BackendServer Plugin -- plugin.py:stop:110
2017-10-20 15:38:32 DEBUG    __init__     Main         BackendServer: shutting down -- __init__.py:stop:162
2017-10-20 15:38:32 INFO     _cplogging   Main         [20/Oct/2017:15:38:32] ENGINE HTTP Server cherrypy._cpwsgi_server.CPWSGIServer(('192.168.178.41', 8383)) already shut down -- _cplogging.py:error:219
2017-10-20 15:38:32 DEBUG    __init__     Main         BackendServer: engine exited -- __init__.py:stop:165
2017-10-20 15:38:32 DEBUG    plugin       Main         Stopping knx Plugin -- plugin.py:stop:110
2017-10-20 15:38:32 DEBUG    plugin       Main         Stopping visu Plugin -- plugin.py:stop:110
2017-10-20 15:38:32 DEBUG    plugin       Main         Stopping smartvisu Plugin -- plugin.py:stop:110
2017-10-20 15:38:32 DEBUG    plugin       Main         Stopping sql Plugin -- plugin.py:stop:110
2017-10-20 15:38:32 DEBUG    plugin       Main         Stopping simulation Plugin -- plugin.py:stop:110
2017-10-20 15:38:32 INFO     __init__     Main         Exit Simulation -- __init__.py:stop:63
2017-10-20 15:38:32 DEBUG    plugin       Main         Stopping sma_em Plugin -- plugin.py:stop:110
2017-10-20 15:38:33 INFO     smarthome    Main         Thread: sma_em, still alive -- smarthome.py:stop:393
2017-10-20 15:38:33 INFO     smarthome    Main         Thread: Main, still alive -- smarthome.py:stop:393
Exception ignored in: <module 'threading' from '/usr/lib/python3.5/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 1288, in _shutdown
    t.join()
  File "/usr/lib/python3.5/threading.py", line 1054, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.5/threading.py", line 1070, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
  File "smarthome.py", line 399, in stop
    exit()
  File "/usr/lib/python3.5/_sitebuiltins.py", line 26, in __call__
    raise SystemExit(code)
SystemExit: None

[psilo]

whe das hat aber eigentlich eine stinknormale implementierung:

    def run(self):
        """
        Run method for the plugin
        """
        self.alive = True

        while self.alive:
            emparts = self.readem()
            if self._serial == format(emparts['serial']):
                if 'pregard' in self._items:
                    self._items['pregard'](emparts['pregard'])
                if 'psurplus' in self._items:
                    self._items['psurplus'](emparts['psurplus'])
                if 'pregardcounter' in self._items:
                    self._items['pregardcounter'](emparts['pregardcounter'])
                if 'psurpluscounter' in self._items:
                    self._items['psurpluscounter'](emparts['psurpluscounter'])
                if 'cosphi' in self._items:
                    self._items['cosphi'](emparts['cosphi'])
            time.sleep(self._time_sleep)

    def stop(self):
        """
        Stop method for the plugin
        """
        self.alive = False

Was hast Du für sleep gesetzt? Evtl. dauert es halt etwas bis es sich beendet, weil es gerade im sleep Block hängt (default ist 5 Sekunden)

[whe]

wo kann ich denn "sleep" setzen ?

passiert auf einem Pi3; der ist doch recht schnell.

[psilo]

ich hatte das bei mir noch nie, es gibt diverse plugins die dauerhaft einen thread so öffnen wie ich im plugin. ich habe aber auch was deutlich schnelleres als einen rpi im einsatz. vielleicht gibt es hier ja noch mehr nutzer des plugins mit erfahrungen?

ich kann aber mal schauen, ob ich es scheduler gesteuert mache. aber das macht eigentlich wenig sinn, wenn ich alle paar Sekunden den wert auslese. theoretisch stellt das energy meter den sogar noch öfter als alle 5 Sek neu zur verfügung..

zum time_sleep siehe readme...

### plugin.conf (deprecated) / plugin.yaml

```
[sma_em]
    class_name = SMA_EM
    class_path = plugins.sma_em
    serial = xxxxxxxxxx
    time_sleep = 5
```

```yaml
sma_em:
    class_name: SMA_EM
    class_path: plugins.sma_em
    serial: xxxxxxxxxx
    time_sleep: 5
```

#### Attributes
  * `serial`: The serial number of your energy meter
  * `time_sleep`: The time in seconds to sleep after a multicast was received. I introduced this to avoid too many values to be processed

[whe]

sorry und danke, habe es gerade auch gefunden.

das Problem liegt hier wahrscheinlich auch daran, dass das PlugIn bei mir nicht läuft, weil ich keinen SMA EM betreibe.
ich bereite den Pi für meinen Sohn vor.

ist aber trotzdem unschön, wenn es solche Hänger gibt; kann man das nicht abfangen und eine saubere Fehlermeldung ausgeben ?

[psilo]

whe wenn ich wüsste was das DAS ist, was ich abfangen muss.. Das Ding horcht einfach aufs Netzwerk und liest einen Mutlicast aus... Ich habe keinen Schimmer was da bei Dir genau passiert, weil es hier eben nicht passiert..

[psilo]

PS: wenn ich die IP ändere, die zu prüfen ist, kriege ich das Problem auch rein. Ich habe aber ehrlich gesagt wenig Ahnung, wie ich erkennen kann ob an diese IP Daten via Multicast hingesendet werden, oder nicht.
Ich habe das Plugin ja mit freundlicher Genehmigung dieses Projekts gebaut (https://github.com/datenschuft/SMA-EM), der Code ist also teilweise nicht mal von mir.

Wenn man keine Fritzbox hat, das AVM Plugin aber reinnimmt. gibt es ja logischerweise auch Fehler. Jede Unwägbarkeit kann man mE. nicht abfangen. Kommentiere es halt aus, testen kannst Du das Ganze ja sowieso erst vor Ort.

[psilo]

Ich habs jetzt nochmal mit try except Blöcken versucht, offenbar bringt das bei dem rohen Netzwerkzeug nichts.. Wenn jemand eine Idee hat, was das DAS genau ist und wie ich es abfange gerne her damit. Ansonsten: Plugin nur nutzen wenn man das zugehörige Gerät auch hat