Jump to content

thunderbird

Members
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    225

  • Benutzer seit

  • Letzter Besuch

 Inhaltstyp 

Posts erstellt von thunderbird

    Wetterstation

    in Projektvorstellungen und Projektideen

    Geschrieben

    Nachdem ich die letzen Wochen nicht so viel Zeit hatte, geht es jetzt endlich wieder an der Wetterstation weiter. In der letzten Woche hatte mein VServer – Hoster einige Probleme mit den Servern, so dass die Wetterstation zeitweise nicht erreichbar war. Jetzt läuft aber alles wieder so wie es soll. Ich habe bei beiden Stationen ein Voltage/Current Bricklet eingebaut, so dass jetzt auch Akkuspannung und Strom überwacht werden können. Das ist besonders bei der Station wichtig, die später ein bisschen weiter entfernt stehen soll, um rechtzeitig eingreifen zu können. Insgesamt läuft die UMTS-Station aber sehr zuverlässig. Heute habe ich mich ein bisschen um die Bereitstellung der Daten vom Server gekümmert. Alle Daten werden jetzt als JSON-String ausgeliefert. So ist es einfacher die Daten in Diagrammen dazustellen, was ich bald machen möchte.

    Wetterstation

    in Projektvorstellungen und Projektideen

    Geschrieben

    Also bis jetzt habe ich noch keine Heizung so kalt wars einfach noch nicht. Aber ich denke ich werde bald mal eine Heizfolie nachrüsten. Da gibt es ja diverse kleine Folien die man von unten in den Trichter kleben kann. Werde ich aber berichten wenn ich da was dran mache.

     

    Im Moment arbeite ich noch an der Software da sind einige Anpassungen notwendig.

    TF Protocol 2.0 Beta

    in Allgemeine Diskussionen

    Geschrieben

    @borg: Also wenn ich bei einem bestehenden Master - Slave System V1  ein Update auf V2 mache läuft alles problemlos.

    Habe ich aber eine ganz neue RS485 und einen MasterBrick mit V2 kann ich die RS485 nicht direkt auf dem "Master Modus" umschalten. Dazu muss ich erst wie Einstein beschrieben hat vorgehen.

     

    Das Problem hatte ich auch. Geh mal unter configure extension type und bestätige nur das was schon da steht. Danach kannst du auch nen master konfigurieren. Ich hab bisher nur noch nicht rausgefunden an was das liegt.

     

    Kein Thema. Die V2 hat für mich einige Vorteile von daher teste ich immer gerne ;-)

    TF Protocol 2.0 Beta

    in Allgemeine Diskussionen

    Geschrieben

    Ich denke ich habe das Problem gefunden. Wenn ich den Wert der Funktion auf "false" setzte

    temp.setResponseExpectedAll(false);

    dann läuft es so wie es soll.

     

    Ich denke da sind in der Device Klasse die flag Einträge vertauscht.

    Default müsste sein => RESPONSE_EXPECTED_FLAG_FALSE

    Ist der Übergabewert true sollte flag => RESPONSE_EXPECTED_FLAG_TRUE sein.

     

    public void setResponseExpectedAll(boolean responseExpected) {
	byte flag = RESPONSE_EXPECTED_FLAG_TRUE;
	if(responseExpected) {
		flag = RESPONSE_EXPECTED_FLAG_FALSE;
	}

     

    Ob das in allen Bindings so ist weiß ich nicht. Das ist JAVA

    TF Protocol 2.0 Beta

    in Allgemeine Diskussionen

    Geschrieben

    Hallo borg,

    ich habe das mal mit setResponseExpected getestet. Ich habe aber setResponseExpectedAll genutzt weil ich sicher gehen wollte, dass es bei allen Funktionen so ist. Leider kann ich keine Änderung feststellen. Ich kann einfach einen beliebigen Sensor nehmen und einen Callback anhängen ohne das ich eine Exception bekomme, obwohl der Sensor garnicht angeschlossen ist.

    Nutze ich aber 

    temp.setResponseExpected(BrickletTemperature.FUNCTION_SET_TEMPERATURE_CALLBACK_PERIOD, true);

     

    bekomme ich eine Exception da schein irgendwas in der Funktion setResponseExpectedAll nicht ganz ok zu sein.

     

     

    Setter erwarten Standardmäßig auch in neuen Protokoll keine Antwort, man kann es aber anstellen. Ist allerdings anscheinen noch nicht dokumentiert ???.

     

    Alle Devices haben die folgenden 3 Funktionen:

     

    public void setResponseExpected(byte functionId, boolean responseExpected);
public boolean getResponseExpected(byte functionId);
public void setResponseExpectedAll(boolean responseExpected)

     

    d.h. du müsstest 

    temp_bricklet.setResponseExpected(TemperatureBricklet.SET_TEMPERATURE_CALLBACK_PERIOD, true);

    aufrufen können und dann auch einen Timeout bekommen!

     

    Edit: Allerdings bringst du mich da auf eine Idee, vielleicht sollten die CallbackPeriod und CallbackThreshold setter als Standardeinstellung alle responseExpected = true haben. Mit dem Hintergedanken: Die beiden Setter werden meist nur einmal beim starten des Programms aufgerufen und sind nicht relevant für die Performance.

     

    Wenn jemand aus irgendwelchen Grüden die Periode oder den Threshold oft ändern muss, kann er es ja wieder zurück setzen. Mhmhmhmh

    TF Protocol 2.0 Beta

    in Allgemeine Diskussionen

    Geschrieben

    Moin Moin,

    ja es wäre eine sehr gute Idee das für set*CallbackPeriod immer aktiv zu haben.

     

    Mir ist da noch was aufgefallen. Es passiert ab und an schonmal das ein Bricklet (aus welchen Gründen auch immer ) nicht mehr antwortet. Da ich nur mit Callbacks arbeite finde ich das erst dann raus wenn irgendwas offensichtlich nicht mehr geht ( Es regnet es wird aber vom IO4 Bricklet kein Callback ausgelöst). Das ist dann immer recht ärgerlich. Deswegen habe ich mir überlegt (wurde auch schonmal hier diskutiert) meinetwegen jede Stunde alle Bricklets an zu "pingen". Soweit kein Problem, die Methode getIdentity() ist da ja gut für geeignet. Hat man aber jetzt eine Liste aus Devices bekommt man das Problem das man erstmal rausfinden muss was das für ein Bricklet/Brick war damit man es Casten kann und die Methode ausführen kann. Wäre es nicht möglich diese Methode (soweit ich das gesehen habe ist sie ja bei jedem Brick/Bricklet verfügbar) in die Device Klasse zu schieben ?

    Oder gibt es da eine schönere Lösung zu ??

    TF Protocol 2.0 Beta

    in Allgemeine Diskussionen

    Geschrieben

    Danke borg. Ich werde das mit dem brickd mal morgen testen.

    Mir ist aber noch was aufgefallen.

     

    Wenn ich einen Callback benutze am Temp. Bricklet und den mit temp.setTemperatureCallbackPeriod(1000); einstelle, sollte meiner Meinung nach eine TimeoutException ausgelöst werden wenn kein Brick oder Bricklet an den PC angeschlossen ist.

    Spätestens wenn man dann den Listener mit temp.addListener hinzufügt sollte ja was passieren.

     

    Aber da tut sich nichts. Ist das normal ??

    TF Protocol 2.0 Beta

    in Allgemeine Diskussionen

    Geschrieben

    Super Danke.

    Also ich konnte den Fehler wieder beobachten. Das ganze passiert wenn mein Programm läuft und man den Master per Reset neustartet. Dann geht die CPU-Last hoch und das Log wird innerhalb von Sekunden extrem groß(1GB).

     

    Ich benutze die Java Bindings mit Callbacks (Temperatur)

    Plattform ist 64 Bit

     

    Könntet ihr bitte noch den Brickd für den Raspberry Pi (arm) als deb Paket bereitstellen? Dann würde ich das dort auch sofort testen ;-)

     

    Hier mal das LOG

    2012-12-22 16:33:18.958975 <I> <main_linux.c:275> Brick Daemon 2.0.0 started (daemonized)
2012-12-22 16:33:19.193359 <I> <usb.c:137> Added USB device (bus: 2, device: 6) at index 0: Master Brick [67N4R3]
2012-12-22 16:34:14.630459 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:35:20.991206 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:35:27.535909 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:35:36.839606 <I> <client.c:61> Socket (handle: 18) disconnected by client
2012-12-22 16:35:39.685049 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:35:44.676683 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:35:48.520440 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:36:02.533402 <I> <client.c:61> Socket (handle: 18) disconnected by client
2012-12-22 16:36:03.983742 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:36:09.237350 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:36:14.174956 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:36:18.364469 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:36:59.951934 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:37:02.877460 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:37:10.114530 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:37:15.943577 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:37:49.366481 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:38:25.558476 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:38:27.828234 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:39:14.282072 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:39:20.523027 <W> <transfer.c:60> Read transfer 0x18d9d40 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523162 <W> <transfer.c:60> Read transfer 0x18d9db8 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523524 <W> <transfer.c:60> Read transfer 0x18d9e30 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523737 <W> <transfer.c:60> Read transfer 0x18d9c50 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.524057 <W> <transfer.c:60> Read transfer 0x18d9cc8 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.565888 <I> <usb.c:262> Removing USB device (bus: 2, device: 6) at index 0: Master Brick [67N4R3]
2012-12-22 16:39:20.569079 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569109 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569129 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569139 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569152 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569161 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569172 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569182 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569194 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569203 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569214 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569223 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569234 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569244 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569270 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569279 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569290 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569298 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569308 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)

    Temperatur Bricklet defekt?

    in Hardware

    Geschrieben

    Ahh Problem gefunden!!!

    Ich habe mir von dem "defekten" Bricklet mal die UID angesehen(Über den Load Button im Flashing Menü). Diese war bei mir "1" ich habe sie wieder auf einen richtigen Wert gesetzt jetzt sehe ich das Bricklet wieder.

     

    Danach habe ich nochmal ein Update auf 1.0.0 gemacht und wieder auf 1.1.1. Dabei war wieder alles normal.

    Temperatur Bricklet defekt?

    in Hardware

    Geschrieben

    Hallo ich habe das Problem auch. Ich wollte gerade einen kleinen Test aufbauen dazu habe ich zuerst den Master auf 1.4.6 gebracht danach das Temp. Bricklet auf 1.1.1. Danach ist das Bricklet nicht mehr zu sehen. Nochmaliges Flashen ist problemlos möglich aber das Bricklet taucht nicht mehr auf. Ich habe ein weiteres Temp. Bricklet angeschlossen was schon die Firmware 1.1.1 hatte das läuft problemlos. Brickv und Brickd sind auf dem neusten Stand.

    Wetterstation

    in Projektvorstellungen und Projektideen

    Geschrieben

    Es ist jetzt eine Woche her das ich die Updates gemacht habe. Seitdem konnte ich keine Probleme mehr feststellen :-)

    Ich hoffe das das so bleibt.

     

    Gestern habe ich meine zweite Station erfolgreich mit UMTS in Betrieb genommen. Die Daten der Sensoren laufen jetzt über einen Raspberry Pi und UMTS an den Server. Erstmal werde ich jetzt noch ein bisschen testen  ob das auch alles stabile läuft dann kommt die Station an den richtigen Ort.

    IMG_0315.geaendert.JPG.7e8bde10f1b64e91d90bd569e48a10c3.JPG

    IMG_0314.geaendert.JPG.fcd7ed2891d2b133953bf986d0b7b2a8.JPG

    IMG_0316.geaendert.thumb.JPG.1d825a77ed8df5b0845ff632c99b421b.JPG

    IMG_0318.geaendert.thumb.JPG.fe1a94294094236668f7a9fd8774bdfa.JPG

×
×
  • Neu erstellen...