Temperaturabfrage timeout nach 10s normal?

[rifmetroid]

Ich würde die DC Power Supply von Phoenix Contact auch nicht unbedingt außer Acht lassen. Teste doch mal, wie sich das Ganze verhält, wenn du die Power Supply außerhalb des Gehäuses hast und nur die TF-Sachen im Gehäuse.

 

Ich kenne einen Anwendungsfall, da haben wir Netzteile quer liegend eingebaut, da gab es nach gewisser Zeit Probleme mit der Wärmeabfuhr in deren Gehäuse, da sie nur für hochkant stehenden Einbau konzipiert waren (Position der Lüftungsschlitze beachten, sollten immer oben und unten sein).

[jax]

Also es läuft gerade mal in der Vertikalen Position. Mal schauen wie lange dass es so läuft. Batti möchtest Du die Lufttemperatur im Kasten oder mit einem Anlegethermometer vom AOZ1212 des Step Downs? (Der ist zwar auch bis 85°C geratet...). Danke für die Ideen! Ich messe jetzt auch Strom und Spannung mit. Resultate folgen gleich. Beste Grüsse

[jax]

Konnte die Antenne nun auch auf der Aussenseite montieren um diese auch richtig auszurichten. Leider stürzt er immer noch ab nach einer gewissen Zeit. Ich kann nur noch probieren das Netzteil aus dem Kasten zu nehmen. Unten noch ein Bild wie jetzt getestet wurde... muss doch so laufen, nimmt ja kaum Strom auf das zeugs, misst ja nur 3 Temperaturen... was mach ich falsch?

 

[jax]

Dazu wollte ich auch noch fragen: Kann man kritische Parameter aus dem Master brick auslesen wie "Open Connections" (der kann ja nur 15 oder?) oder wie voll gewisse Buffers sind? Würde das Debuggen deutlich einfacher machen...

[batti]

Die Lufttemperatur im Kasten würde mir reichen. Wenn du diese Messen kannst, dann gerne auch die Chip Temperatur.

Die Drehung des Kastens ist echt eine gute Idee gewesen. Bin auf das Ergebnis gespannt.

 

Die Anzahl der "Open Connections" lässt sich nicht auslesen. Der Bufferzustand lässt sich mit getWifiBufferInfo() auslesen.

[jax]

Läuft schon besser vertikal...

 

Was mir noch auffällt ist folgendes. Ich hab das genau gleiche Setup im Keller, dort zeigt der Step-Down immer 0mA. Der Kasten hier oben zeigt aber stets so 130mA. Hier die Messungen:

 

hier oben:

51.1 °C 24.234 V 128 mA

WiFI Buffers: WifiBufferInfo(overflow=0, low_watermark=1497, used=0) WifiStatus(mac_address=(114, 22, 160, 94, 248, 32), bssid=(116, 85, 189, 126, 29, 0), channel=11, rssi=-72, ip=(110, 5, 168, 192), subnet_mask=(0, 255, 255, 255), gateway=(1, 5, 168, 192), rx_count=763620, tx_count=3413202, state=1)

23.68 23.94 23.82

 

unten im Keller:

24.0 °C 23.643 V 0 mA

WiFI Buffers: WifiBufferInfo(overflow=0, low_watermark=1499, used=0) WifiStatus(mac_address=(247, 21, 160, 94, 248, 32), bssid=(82, 40, 17, 116, 127, 104), channel=11, rssi=-40, ip=(136, 5, 168, 192), subnet_mask=(0, 255, 255, 255), gateway=(1, 5, 168, 192), rx_count=10, tx_count=68, state=1)

15.04 15.16 15.1 14.74

Traceback (most recent call last):

  File "./manage.py", line 10, in <module>

    execute_from_command_line(sys.argv)

  File "/Users/gabejackson/venv/brewery/lib/python2.7/site-packages/django/core/management/__init__.py", line 399, in execute_from_command_line

    utility.execute()

  File "/Users/gabejackson/venv/brewery/lib/python2.7/site-packages/django/core/management/__init__.py", line 392, in execute

    self.fetch_command(subcommand).run_from_argv(self.argv)

  File "/Users/gabejackson/venv/brewery/lib/python2.7/site-packages/django/core/management/base.py", line 242, in run_from_argv

    self.execute(*args, **options.__dict__)

  File "/Users/gabejackson/venv/brewery/lib/python2.7/site-packages/django/core/management/base.py", line 285, in execute

    output = self.handle(*args, **options)

  File "/Users/gabejackson/Documents/pycharm/bcs/bcs/brewery/management/commands/kegerator.py", line 47, in handle

    t_top = ptc_top.get_temperature()/100.0

  File "/Users/gabejackson/venv/brewery/lib/python2.7/site-packages/tinkerforge/bricklet_ptc.py", line 118, in get_temperature

    return self.ipcon.send_request(self, BrickletPTC.FUNCTION_GET_TEMPERATURE, (), '', 'i')

  File "/Users/gabejackson/venv/brewery/lib/python2.7/site-packages/tinkerforge/ip_connection.py", line 878, in send_request

    raise Error(Error.TIMEOUT, msg)

tinkerforge.ip_connection.Error: -1: Did not receive response for function 1 in time

 

Die erste zahl ist die core temp. Im Keller beträgt diese lediglich 24°C...und lief schon eine Stunde. Aber eben, hat gerade wieder einen Timeout von über 30s gegeben und demzufolge der Fehler oben. Ich habe den Kasten auch sofort geöffnet und alles berührt.. da ist nicht mal etwas annähernd warm. Hier oben ist die Temperatur halt bisschen wärmer (Bodenheizung) aber im Kasten wirds auch nur so 26-27°C (gemessen).

 

weitere Bemerkungen: im Keller macht der nicht mal reset, der status ist einfach alle lichter an (grünes licht von wifi ist permanent als wäre es verbunden), nicht mal der Reset knopf geht auf dem Master brick! aber verbinden kann ich nicht. Wenn ich probiere zu verbinden mit der python lib dann hängt der prozess und ich muss ihn via kill herunterfahren. manchmal rebootet er aber auch anstelle des lock-ups...

 

sind euch diese Zustände bekannt?

[batti]

Die Strommessung bei der Step-Down Power Supply ist für kleine Ströme nicht sonderlich genau. Das kann also sein. Bezüglich der Chip Temperatur, wie gesagt das können bei 51°C in real genausogut 20°C wie auch 80°C sein. Ich bin mir momentan ehrlich gesagt nicht sicher ob es überhaupt an der Temperatur liegt.

 

Läuft denn auch der Kasten oben bei dir stabil wenn er offen ist? Hast du das mal längere Zeit getestet?

[jax]

hab nicht aufgegeben.. bin am messen. heute ist noch ein neues Relais gekommen um den Gefrier-kompressor zu schalten: http://www.crydom.com/en/Products/Catalog/s1_dr.pdf DR24D12R

braucht nur sehr wenig Strom zum schalten (Industry Digital Out kann ja nur 25mA). Aber ja, zuerst muss ich schauen, dass das Teil überhaupt 24/7 läuft, sonst bringt es gar nicht erst zu schalten...

[jax]

Also ich habe das Problem gefunden. Es ist eher ein WiFi/TCP-IP Problem als etwas mit dem Master. Der Master stürzt nicht ab, sondern hat nur netzwerk probleme. Ich habe mein Skript nun so geändert, dass er automatisch re-connectet - ohne das reconnect des APIs.

 

nun kriege ich folgende resultate:

Statistics: Total run-time: 8:39:07.261778, Number of disconnects: 30

Er ist zwar kurzzeitig nicht erreichbar, kann jedoch jeweils nach einem Retry wieder verbinden.

 

Den code habe ich in etwa so geschrieben:

 

        disconnects = 0
        ipcon = IPConnection()
        ipcon.set_auto_reconnect(False)
        ipcon.set_timeout(2.5)

        master = Master(settings.TINKERFORGE_CONFIG['kegcontrol']['MASTER'], ipcon) # Create device object
        ptc_top = PTC(settings.TINKERFORGE_CONFIG['kegcontrol']['PTC_AIR_TOP'], ipcon)
        ptc_bottom = PTC(settings.TINKERFORGE_CONFIG['kegcontrol']['PTC_AIR_BOTTOM'], ipcon)
        ptc_water = PTC(settings.TINKERFORGE_CONFIG['kegcontrol']['PTC_WATER'], ipcon)

        ido4 = IndustrialDigitalOut4(settings.TINKERFORGE_CONFIG['kegcontrol']['IDO_COMPRESSOR'], ipcon)

        ipcon.connect(
            settings.TINKERFORGE_CONFIG['kegcontrol']['HOST'],
            settings.TINKERFORGE_CONFIG['kegcontrol']['PORT']
        )

        ptc_top.set_wire_mode(PTC.WIRE_MODE_4)
        ptc_bottom.set_wire_mode(PTC.WIRE_MODE_4)
        ptc_water.set_wire_mode(PTC.WIRE_MODE_4)

        # Get initial compressor state
        state = ido4.get_value()

        start_time = timezone.now()
        while True:
            end_time = timezone.now()
            run_time = end_time - start_time
            try:
                t_top = ptc_top.get_temperature()/100.0
                t_bottom = ptc_bottom.get_temperature()/100.0
                t_water = ptc_water.get_temperature()/100.0
                avg_air = (t_top+t_bottom)/2
                print "Temp 1: %s °C Temp 2: %s °C Temp 3: %s °C Online: %s" % (t_top, t_bottom, t_water, run_time)
            except Error as e:
                print e
                end_time = timezone.now()
                run_time = end_time - start_time
                print "Detected disconnect", run_time, ipcon.get_connection_state()
                ipcon.disconnect()
                connected = False
                disconnects += 1
                retries = 0
                while not connected:
                    try:
                        print "Reconnecting..."
                        ipcon.connect(
                            settings.TINKERFORGE_CONFIG['kegcontrol']['HOST'],
                            settings.TINKERFORGE_CONFIG['kegcontrol']['PORT']
                        )
                        connected = True
                        print "Reconnected after %d retries!" % retries
                    except IOError:
                        print "Connecting failed, retrying (%d)..." % retries
                        retries += 1
                        sleep(1)
                        pass
            sleep(1)

 

so bleiben die Komponenten zuverlässlich kontrollierbar.

 

Hoffe das hilft jemandem.

 

Beste Grüsse,

 

Gabe

[Unexpected]

Hallo jax,

 

ich hab mir eigentlich alle Posts hier durchgelesen, dennoch auf die Gefahr hin dass es schon jemand geschrieben hat, meine Idee zu deinem letzten Post.

 

Wenn es immer wieder disconnects gibt, ist evtl. dein WLAN an der Stelle schwach bzw. immer wieder gerade so da und dann wieder weg?

 

Grüße

Unex

[jax]

Ja das ist so. Ich habe auch in letzter Zeit mit den Antennen rumgespielt um diese besser auszurichten. Jetzt ist besser. Genau das ist auch das Problem mit dem Teil im Keller, der ist über eine Wireless Bridge mit dem Netzwerk hier oben verbunden, das geht aber durch 2 Stahlbeton Wände durch, deshalb kommt es vor, dass es z.T packet-loss gibt. Aber ich teste nun schon 24h durch und es funktioniert nun prächtig. Ab und zu gibt es disconnects, aber jeweils nur 1 paket, dann sofort wieder da.

 

Danke für all die Ideen und Hilfe!

[Unexpected]

Freut mich das es nun läuft!

[batti]

Na das hört sich doch gut an... Freut mich.