thunderbird

Jetzt kanns weiter gehen :-)

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.

Ist die getIdentitiy Methode in der ersten Version dann auch schon in der Device Klasse ??

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.

@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. Kein Thema. Die V2 hat für mich einige Vorteile von daher teste ich immer gerne ;-)

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

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.

Danke! Das hat geklappt. Hmm da scheint dann noch irgendwie nen Fehler drin zu sein.

Hmmm ich habe da auch noch was gefunden. Bis jetzt hatte ich immer RS485 Extensions die schon eine Config hatten. Jetzt habe ich eine ganz neue. Da bekomme ich beim Speichern der Config einen Fehler. Es schein was mit der "Rolle" Master zu tuen zu haben. Meine Slave Einstellungen kann ich problemlos speichern.

@ Einstein Das Problem was du im Brickd siehst, kannst du lösen in dem du dir das Paket auf der ersten Seite von photron suchst oder den Brickd aus git selber baust. In dem fertigen Paket ist noch ein Fehler. Mit der WiFi Extension kann ich leider nicht helfen. Gruß Sven

Konnte bis jetzt keine Probleme mehr feststellen. Das Problem mit der CPU Auslastung konnte ich mit dem neuen BrickD nicht mehr produzieren ;-)

Super hab ich gerade geladen und installiert. Werde ich jetzt mal testen.

@getIdentitiy in Device Klasse: jopp das sollte passen. Mach ich weiß aber nicht ob ich das heute noch schaffe.

Soo habe jetzt meine beiden Stationen und meine Testumgebung auf 2.0 umgestellt läuft alles soweit gut :-) Auch auf dem Raspberry läuft alles. Was nicht geklappt hat ist das Auto Update für das Temp-IR Bricklet da hat er angezeigt neuste Version ist 0.0.0. Von Hand lief das aber problemlos.

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 ??

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 ??

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)

Gibt es irgendwo ein Log vom Brickd ?? Ich glaube da ist irgendwas im Busch. Ich habe gerade ein Callback für ein Temp. Bicklet geschrieben. Das läuft zwar auch aber nur mit 100% CPU Auslastung.

@ photron Das Problem mit der UID scheint irgendwie mit dem Update zu tuen zu haben. Vor dem Update war die UID im Brickv sichtbar und das Bricklet problemlos ansprechbar. Erst danach war sie 1.

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.

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.

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.

Ich habe jetzt alles auf den aktuellsten Stand gebracht und werds jetzt nochmal laufen lassen mal sehen was passiert. Ich melde mich hier sobald sich was ändert.

Danke :-) ich habe jetzt mal einen älteren Switch eingebaut. Werde es jetzt mal testen Danke !

Hallo ArcaneDraconum, hört sich interessant an ich nutze den Rasp. im Moment direkt an so einem DLan Adapter weil ich im Gartenhaus nunmal kein Lan liegen habe ;-) Dann werd ich mal ein langes Kabel testen oder ich hänge testweise noch einen Switch dazwischen. Danke für den Hinweis :-)