PanStamp Board RGB,CW,WW;DMX;IR

Begonnen von ext23, 22 Juli 2013, 22:13:18

Vorheriges Thema - Nächstes Thema

joshi04

Hallo zusammen,
muss hier mal vorsichtig nachfragen. Soweit ich verstanden habe, fragt bei einem "Systemstart" (shutdown restart, reread config, etc.) der panStick alle Stamps einmal ab. Das führt bei meinen 10 panStamps leider regelmäßig zu TRANSMIT LIMIT EXCEEDED.
Gibt es eine Möglichkeit daran etwas zu ändern, oder mache ich etwas falsch? Wie macht Ihr das? Habt Ihr das auch?

Zugegeben, ein Schönheitsfehler, da im Betrieb das Limit ausreicht und ein Schönheitsfehler, wie die bekannten PERL WARNING: Subroutine SWAP_Initialize redefined at...
Schöne Grüße,
John
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

ext23

Moin,

naja die FW ist ja offen, könntest diese Funktion also ganz rauswerfen ;-)

Ist bei mir zum Glück noch nicht aufgetreten. Ich hab aber nur 2 Temp Boards. Das RGB Board habe ich erstmal raus geworfen weil das irgendwie alles nicht richtig funktioniert. Da kommen ständig die Befehle nicht an. Schaltet also extrem unzuverlässig. Dann flackert beim starten des Fading das Licht manchmal wild umher etc. Dann geht es in der Nacht manchmal von allein an und ach naja, ka.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

justme1968

@joshi04: der fhem muss das gesamte netz einmal abfragen um an die relevanten internals zu kommen. das sind aber pro panstamp nur 2 nachrichten die gesendet werden. damit kommst du noch lange nicht ans limit.

jedenfalls im normalfall wenn du nicht die config direkt bearbeitest. einer der gründe warum das nicht empfehlenswert ist ist das fhem dabei jedes mal neu gestartet wird. das ist wirklich nicht nötig.

die frage ist also warum bei dir das system so oft neu gestartet wird das es zur meldung kommt.

die perl warnungen sind keine schönheitsfehler sondern liegen genau am reread config und ganz normal.


@ext23: meine arbeiten absolut zuverlässig. monate bzw. jahre lang. es ist also vermutlich nicht die firmware sondern etwas anderes.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ext23

Mhh, bei mir passieren sehr komische Sachen. FW Version 00020003. Ich habe auch immer ein Haufen Sent_unconfirmed.

RSSI liegt bei -75.5 was reichen sollte. Nun ist die Frage die das RSSI bei dem Modul aussieht.

Gibt es denn eigentlich schon neue Versionen auch wegen der anderen IR Lib? Ich bekomme da immer viele Anfragen per Mail ob es da schon was Neues gibt, bzw. wie es mit NRG und der neuen Arduino IDE Version aussieht etc.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

joshi04

Zitat von: justme1968 am 20 Juni 2016, 12:18:29
die frage ist also warum bei dir das system so oft neu gestartet wird das es zur meldung kommt.
Der Grund dafür liegt außerhalb von FHEM.  ;)
Ich werde versuchen, mir das abzugewöhnen. Vielleicht könnte es auch daran liegen, dass von den 10 panStamps 3 derzeit offline sind.

Die Perl Warnungen kommen bei mir nicht bei einem reread config (da hielte ich die ebenfalls für völlig normal), sondern bei einem shutdown restart. Aber ich probiere das einmal auf einem jungfräulichen System, um auszuschließen, dass das an meiner Konfig liegt. Ich vermute also, bei Euch tritt das bei einem shutdown restart nicht auf.

@ Daniel, bei mir funktionieren auch die panStamp mit RSSI von -87,5 noch einwandfrei.
Allerdings hatte ich bei mir auch immer im Verdacht, dass Andrés Entwicklungsumgebung leicht anders ist als meine (ohne das klar identifizieren zu können). Daher laufen bei mir auf allen panStamps das fertig Hex-File, dass Du bei Dir verlinkt hast/im Wiki verlinkt ist.

Manchmal, durch zuviel Testerei an anderen Baustellen, scheinen sich einzelne panStamps "zu verabschieden" (=> value has to be 10 byte(s) in size). Konnte/habe noch nicht genau identifiziert, auf welchem Level sich etwas verabschiedet. Hab mich aber schon mal erfolglos ziemlich totgesucht, bis nach einem kompletten Neustart des Servers dann auf einmal alles wieder lief. Seit dem, muss ich zugeben, nutze ich als einfachste und zuverlässigste Behebung das schnelle durchstarten. Ich weiß, Holzhammer, funktioniert aber zuverlässig und zum detaillierteren debuggen kam ich noch nicht/fehlen mir die SWAP Kenntnisse. Da das aber relativ selten vorkommt...

Alles stört aber nicht den normalen Betrieb und ist daher weniger wichtig.

Schöne Grüße,
John
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

ext23

Mhh, naja bei mir muss das irgendwie mit dem Empfangspegel zu tun haben. Es dauert manchmal bis zu 20 Minuten bis sich eine Farbe einstellt die ich vorher mit FHEM eingestellt habe. Und das erklärt auch warum manchmal das Licht nachts angeht etc. Das sind vermutlich die ganzen Befehle die ich vorher so abgesetzt habe die aber nicht direkt ankamen.

Kann ich im Log irgendwie sehen wenn die Befehle wiederholt werden? Oder ist das echt der Controller der so lange braucht? Dann sollte ich vielleicht doch mal eine andere FW aufspielen.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

joshi04

Eigentlich bist Du doch viel erfahrener als ich, aber ich traue mich trotzdem zu fragen...
Schuss ins Blaue: Wenn ich mir Deine Signatur anschaue (einen ähnlichen Zoo habe ich auch  ;D), hast Du den panStick von den anderen Stick örtlich separiert?

Meine Interfaces sind mittlerweile soweit es geht örtlich etwas verteilt, gefühlt mit erhöhter Zuverlässigkeit.
Macht das überhaupt sinn? Oh je, hoffentlich schaut hier kein Radiotechniker vorbei!  ???

Zitat von: ext23 am 20 Juni 2016, 19:43:57
Kann ich im Log irgendwie sehen wenn die Befehle wiederholt werden? Oder ist das echt der Controller der so lange braucht?
Dazu kann sicherlich Andre etwas sagen.

Schöne Grüße,
John
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

ext23

Naja steht alles im Abstand von 10 cm. Ist schon recht dicht, aber so viel sollte das nun auch wieder nicht ausmachen. Kann natürlich sein das der Empfänger da im Tal der Ahnungslosen ist, aber HM und die anderen Systeme machen es ja auch. Ich hab auch noch nicht so ganz begriffen wann SWAP die Befehle wiederholt wenn keine Bestätigung kommt. Aber ich als Programmier-Legastheniker habe auch immer kein Lust den Code zu durchwühlen den ich sowieso nicht verstehe ;-)

Vielleicht sind die Antenne auch einfach nur schlecht, aber auch hier hatte ich schon mal verschiedenen ausprobiert.

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

joshi04

#698
Hm, nicht so aufgeräumt, wie bei Dir, aber zumindest zum Jeelink auch nicht viel mehr Platz dazwischen.
Meine Antennen hab ich von panStamp.com.

Schöne Grüße,
John

edith: Mist, Foto ist natürlich andersrum. ::)
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

justme1968

ich habe zwei cul, einen mini cul, einen panstamp und einen jeelink auf etwa 15 cm länge an einem aktiven switch stecken. jeelink und minicul haben eine draht antenne, panstamps und die beiden cul eine 'richtige'

die räumliche nähe hat noch kein problem gemacht.

das rgb board das am weiteren weg ist läuft bei rssi -82 komplett zuverlässig. der panstamp hat auch nur eine draht antenne.

kann es sein das mit den antennen etwas nicht stimmt? vielleicht die lötstelle ?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ext23

Ich muss mir das nochmal anschauen wenn ich Zeit habe. Die Antenne am Modem kann ich ausschließen, der Rest läuft ja. Aber es kann natürlich sein, dass die Antenne an dem Board oder vielleicht auch die Briefmarke oder eben die SW misst ist. Deswegen ware der RSSI zum Board natürlich interessant.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

#701
Moin,

so ich habe die Platine jetzt mal abgebaut und 2 Meter neben den Sender gelegt, aber dennoch schaltet diese nur sehr stark verzögert, manchmal aber auch sofort. Bei einem RSSI von -52.5 kann man ja eigentlich auch nicht meckern.

Ich werde jetzt noch einmal ein anderen panstamp ausprobieren. Und dann sagt mal was nehmt ihr als Model panstamp, die neuen NRGs? Die sollen ja angeblich besser sein, oder? Gibt es für die NRGs eine Modem Software?

UPDATE: Mein Kollege hat übrigens dieselben Probleme! Da es bei euch allen geht, muss es ja irgend was mit der Firmware zu tun haben. Da nutzen wir nämlich dieselbe. Ich werd die nochmal kompilieren.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

joshi04

Hallo Daniel,
als Modemsketch funktioniert der von panStamp auch auf einem NRG. Von Haus aus bin ich nicht sicher, ob der da direkt drauf war, wie bei den AVRs. Bei mir hab ich das erst zum laufen bekommen, nachdem ich den explizit mit dem Modelsketch bestückt habe.
Schöne Grüße, John
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

ext23

Moin,

ich hab jetzt mal ein wenig gespielt und mein Output-Board ausgepackt, das hat die original Firmware drauf. RSSI ist ebenfalls -55 und das schaltet sofort und auch zuverlässig! Ich würde somit mal den PanStick ausschließen. Dann haut doch irgend etwas mit der Firmware nicht hin.

@Andre: habe ich wirklich die richtigen Versionen?!?
Meine Config:
#ifndef CONFIG_H
#define CONFIG_H

//#define USE_SOFT_PWM

#define ENABLE_IR_RECV
#define ENABLE_IR_SEND
#define ENABLE_DMX
//#define ENABLE_REPEATER
#define ENABLE_LED_POWER
//#define ENABLE_BRIGHTNESS

//#define MAX_CHANNELS 3

//#define LED_DEBUG

#ifdef ENABLE_LED_POWER
#  define LED_POWER_PIN A1
#endif

#ifdef ENABLE_BRIGHTNESS
#  define BRI_PIN A2
#endif

#endif


Arduino Version:
Detecting Arduino software version ...  1.0.5 (1:1.0.5+dfsg2-2)

Sketch Version kann ich dir leider nicht sagen, die steht nirgends in den Files. Ich lade mir jetzt nochmal die letzte Version vom Sketch runter und versuche es nochmal. Da muss doch irgend etwas faul sein.

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

#704
Mhh neu kompiliert, geflashed und jetzt läuft es besser, was das denn?!?

Hatte ich eine faule Version am Start, gibts ja nicht. Ich werde beobachten und berichten.

UPDATE: Bei meinem Kollegen läuft es scheinbar auch besser. Es kommt ab und an mal vor das er verzögert aber im großen und ganzen geht es.

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)