panStamp support

[LaSto]

Ich hab grad ein eigenartiges Problem...
Und zwar habe ich mit

set Device setFade 01 FF0000 60
set Device setFade 02 00FF00 60
set Device setFade 03 0000FF 60

definiert. Wenn ich "set Device startFade 01 03" ausführe, bekommme ich im Log ein
"2013.10.02 21:18:10 2: panStamp TRANSMIT LIMIT EXCEEDED"
und es werden alle LED sehr hochfrequent angesteuert.

Definiere ich ein

set Device setFade 01 FF0000 10
set Device setFade 02 00FF00 10
set Device setFade 03 0000FF 10

und starte mit "set Device startFade 01 03" funktioniert es.
Die Zeit die ich als letztes angebe sind doch Sekunden, oder?
Was ist der Maximale Wert?

Gruß
Lars



 

[justme1968]

du hat recht. ich kann es reproduzieren. ich verstehe aber noch nicht ganz was da schief geht...

ich melde mich wenn ich mehr weiss.

gruss
  andre

[justme1968]

ich denke ich weiss was es ist. da ist ein überlauf im code.

kannst du bitte mal in fade.h in zeile 12 aus dem int ein long machen und es noch mal probieren?

ich kann es gerade selber nicht testen weil ich alles mögliche am umstellen bin.

gruss
  andre

[LaSto]

Ich kann momentan auch nicht testen. Der PanStick ist grad auf dem Dachboden in der FritzBox und ich bin übers lange Wochenende unterwegs.
Denke ich werde am Sonntag oder Montag mal testen können.

Gruß
Lars

[justme1968]

ich hab schnell einen anderen panstamp umgeflashed und ohne rgb board getestet.

mein verdacht war richtig. aber es muss noch an einer zweiten stelle etwas geaendert werden. anbei die beiden reparierten files.

gruss
  andre

[LaSto]

So, jetzt bin ich mal dazu gekommen zu testen und es funktiniert.
Vielen Dank Andre!

Ich hänge mal die rgbdriver.zip an.
Das ist jetzt die Version, die sich in der Windows IDE kompilieren lässt und alle Änderungen hat.

Gruß
Lars

[justme1968]

ich habe den rgb sketch inzwischen so weit das er mehr als die 3 kanäle des normalen boards unterstützt.

leider sehe ich aber gerade keine möglichkeit fhem modul und sketch so vor und rückwärts kompatibel zu machen das man die alte und neue version gleichzeitg mit einem aktualiserten fhem modul betreiben kann.

es gibt jetzt zwei lösungen:

- es gibt für die alte und neue version jeweils ein eigenes fhem modul

- zum zeitpunkt x wenn das fhem update kommt müssen auch alle panstamps auf den rgb boards mit dem passenden neuen sketch versehen werden

ersteres ist für die anwender natülich einfacher, letzteres wäre mir lieber und auf dauer einfacher zu pflegen.

da ich gerade nicht weiss ob und wie viele anwender es gibt würde ich den zweiten weg wählen wenn es keine proteste gibt.

gruss
  andre

[ohweh]

Hey,

also ich wär auch für den zweiten Weg... Du baust ja massiv neue Funktionen ein, da ist dauerhafte Pflege mehrerer Module doch recht aufwändig.

Ist SEND-IR im Modul schon implementiert? (auch wenn der Sketch das vielleicht noch nicht hergibt)

Kannste noch ne neue Version des Sketches posten?

Gruss
Oliver

[ntruchsess]

leider sehe ich aber gerade keine möglichkeit fhem modul und sketch so vor und rückwärts kompatibel zu machen

Warum vergibst Du für die (inkompatible) neue Version nicht einfach eine neue Registerid?

Gruß,

Norbert

[justme1968]

das wäre genau variante 1. das mapping fhem modul <-> product code ist 1:1 und damit gäbe es dann zwei fhem module.

inzwischen hab ich noch zwei oder drei ideen wie es doch rückwärts kompatibel gehen könnte aber es ist alles irgendwie unschön und ich weiss nicht ob es den aufwand wert ist. und von denen die es schon gibt werden über kurz oder lang hoffentlich aber sowieso alle wechseln weil der alte sketch und das alte modul nicht weiter entwickelt werden und der neue sketch alles kann was der alte auch kann. es sind ja (noch ) keine dutzende von anwendern aber man muss halt ein eventuell verbauten panstamp zum flashen ausbauen. wenn ein over the air update schon funktionieren würde wäre das gar keine frage.   



gruss
  andre

[ntruchsess]

das wäre genau variante 1. das mapping fhem modul <-> product code ist 1:1 und damit gäbe es dann zwei fhem module.

Du solltest da eine Mapping-tabelle einfügen, sonst kannst Du nie FHEM-module schreiben, die mehrere (funktionell ähnliche) Register in einem Modul bedienen.

- Norbert

[justme1968]

das mapping bzw. diese tabelle gibt es. aber wenn es keine 1:1 zuordnung gibt funktioniert autocreate nicht. von hand das passende modul auszuwählen ist auch jetzt schon kein problem.

zu dem zeitpunkt an dem autocreate aufgerufen wird sind die module ja noch nicht mal geladen und können eine zusätzliche mapping ebene nicht initialisieren. das ganze zentral zu machen würde aber bedeuten das immer irgendetwas editiert werden muss sobald ein neues modul dazu kommt (so wie es zur zeit bei der client liste leider auch schon ist). das funktioniert aber nicht wenn jemand selber private module schreibt und ein fhem update das eigene mapping wieder überbügelt.

das eigentliche problem ist auch nicht das passende modul zu laden sondern das die device description files es nur erlauben versions abhängig register ein und aus zu schalten aber nicht ein register in der größe zu verändern.

das lässt sich zwar alles lösen und wie gesagt habe ich habe inzwischen auch noch ein paar ideen aber ich weiß nicht ob sich der aufwand lohnt so lange niemand schreit weil er den alten sketch weiter verwenden möchte.

gruss
  andre

[Tobias]

Hier ein aktueller Status meiner Panstamps die ich zZ ausschließlich mit Vegetronix Bodenfeuchtesensoren einsetze: (für Andre, fürs Wiki).
Allerdings habe ich noch nicht den neuesten Sketch drauf mit dem Bugfix des 12stündigen sync´s

Code Auswählen Erweitern

set <MyBodenfeuchte> stateFormat VWC_A%
set <MyBodenfeuchte> userReadings Level0_Voltage {hex(ReadingsVal($name,"0C.0-Moisture_level_0","0"))*(3.3/1024)}, VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (ReadingsVal($name,"Level0_Voltage","0"))**4 + 7.10835 * (ReadingsVal($name,"Level0_Voltage","0"))**2 - 0.569557) / ((ReadingsVal($name,"Level0_Voltage","0"))**2 + 1))}, voltage:0B-Voltage {hex(ReadingsVal($name,"0B-Voltage","0"))*0.001}, battery:0B-Voltage {(ReadingsVal($name,"voltage","0")<1?"low":"ok")}

[Tobias]

Ich wieder...
Habe meine 868Mhz Groundplane-Antenne vom externen RasPi getrennt und stattdessen einen Panstamp im RepeaterMode drangehangen. Den Originären Panstamp mit ModemSketch ist nun wieder direkt an meinem Server im Keller eingesteckt.

Den Panstamp-Repeater habe einen Binout2 Sketch verpasst, Repeater-mode aktiviert und auf 1Hop geändert.
Fazit: Funktioniert!!! Ich empfange nun sauber im Keller alle(!!) Bodenfeuchtesensore die ich so im Garten verteilt habe!

Code Auswählen Erweitern

2013.12.25 12:57:28 5: panStamp/RAW: /(EE2F)0001105500030C03130005

2013.12.25 12:57:28 5: Panstamp: 0001105500030C03130005 -83 47
2013.12.25 12:57:28 5: Panstamp dispatch 0001105500030C03130005
2013.12.25 12:57:28 4: 01 -> broadcast (1,0-55): status BF_Rasen 0C:03130005
2013.12.25 12:57:45 5: panStamp/RAW: /(EE32)0001105100040C02CE0005

2013.12.25 12:57:45 5: Panstamp: 0001105100040C02CE0005 -83 50
2013.12.25 12:57:45 5: Panstamp dispatch 0001105100040C02CE0005
2013.12.25 12:57:45 4: 01 -> broadcast (1,0-51): status BF_Garten 0C:02CE0005
2013.12.25 12:58:15 5: panStamp/RAW: /(ED2E)000110B500020C02980002

2013.12.25 12:58:15 5: Panstamp: 000110B500020C02980002 -83.5 46
2013.12.25 12:58:15 5: Panstamp dispatch 000110B500020C02980002
2013.12.25 12:58:15 4: 01 -> broadcast (1,0-B5): status BF_Rhodedendren 0C:02980002


aufgrund 01 -> broadcast sieht man, das die Datenpakete über den Repeater im Hop1 empfangen wurden!

DANKE!!!!!

[Tobias]

Hi,
die Repeaterfunktion für die Sensorwerte funktioniert prächtig. Allerdings kommen die Batteriewerte nur noch ca 1-2mal am Tag an. Ohne Repeater sind immer Sensorwert und Batteriewert gleichzeitig angekommen. Gibt es es da einen bekannten Bug?