panStamp support

[Tobias]

Ist warscheinlich wegen der Fritzbox-Diskussion untergegangen:

Danke, damit funktioniert es. Schön ist, das man in den Internals das AdressRegister ablesen kann :) Hab ich jetzt erst gesehen....
SWAP_0A-PeriodicTxInterval    012C

Edit: ich möchte per UserReading ein BatterieIndikator einbauen, wie man es auch von MAX oder HM kennt.
Kann man sagen das unter 1Volt die Batterie gewechselt werden sollte? Oder 0.9V oder 0.85V? Was meinst du? (für Vegetronix VH400, unter 7mA, mindestens 3.3V)
Wenn ich richtig gelesen habe kann das Batterieboard bis 0.8V Batteriespannung eine stabile 3.3V Spannung bereitstellen

Meine Ideen bzgl Erweiterung:
1. Bis zur maximalen Kapazität des panstamps anschließbare Sensoren. Müssen ja keine Bodenfeuchtesensoren sein, sondern nur welche die eine Spannung 0 - 3.3V abgeben.
Ich habe zb. abgesetzt am Gartenhaus 4 große 2m lange "Särge" in denen Tomaten unter einem Dach wachsen. Würde also 4 Sensoren anschließen.

2. hattest du auch schon als Idee, 1-2mal täglich Anfragen des Pansticks beantworten (regSet). Wenn möglich ebenfalls über regSet und Userregister setzbar

3. bei Pulsecounter: ich bin grundsätzlich dafür die Zählerstände beim Stromausfall in Hardware zu sichern. Auch FHEM kann einmal alles verlieren. Deshalb bin ich auch glücklich darüber das es beim DS2324 AVR-Erstz eine eeprom-Sicherung jetzt gibt. (Ein Eingang des ATTiny ist mit 10K an VCC gebunden sowie mit 100uF gepuffert) Wenn man also einen Stromabfall beim panstamp feststellt, sollten die Zählerstände im eeprom gesichert, beim Init daraus ausgelesen und von dort aus weiter gezählt werden.

[justme1968]

es gibt glaube ich (noch?) keine aussage wann die batterie wirklich schlapp macht. ich fürchte es hängt auch nicht nur von der spannung ab sondern auch von der 'qualität' der batterie. das verhalten  wird auch bei unterschiedlichen sketches unterschiedliche sein. ich könnte mir vorstellen das die änderungsrate ein mindestens so wichtiger indikator ist wie der absolutwert. d.h. wenn es zu ende geht vermutlich sehr schnell und plötzlich. wenn der sensor im 'freien' betrieben wird spiel sicher auch die temperaturschwankung zwischen tag und nacht eine rolle und linear ist das ganze vermutlich auch nicht.

wenn ich das ins swap modul direkt einbaue könnte man ein paar mehr dinge berücksichtigen als nur eine feste schwelle. wie wäre es mit zwei schwellen? ein mal warning und ein mal error?

ich habe bei meinen sketches eingebaut das die interne temperatur noch als reading zur verfügung steht. vielleicht kann man die auch mit verwursten. die dinger werden ja so gut wie gar nicht warm und im power down mode erst recht nicht. d.h. es ist eine viel viel bessere annäherung an die umgebungstemperatur als z.b. bei einem raspberry pi.

mein luftdruck sensor läuft übrigens schon fast 3 monate und ist von 1.6 auf 1.54 runter.

um hier wirklich sicher zu sein sollte man auf jeden fall auch das ausbleiben der nachrichten überwachen. z.b. keine nachricht im eingestellten intevall *10. ich glaube das baue ich direkt ins swap modul ein.

1. das sollte kein problem sein. ich kann dir einen sketch bauen das jeden analog eingang als register sendet und ein config register hat bei dem man pro eingang ein bit setzen kann wenn er berücksichtig werden soll. die frage ist ob man gleich den bininp sketch erweitert dann hätte man einen sketch für alles.

2. ja. das kommt auf jeden fall.

3. das funktioniert vermutlich nicht ohne zusätzliche beschaltung. aber ich werde es daniel für die nächste version des batterie boards vorschlagen.
ich kann aber mal versuchen das in den sketch einzubauen wenn du es probieren magst. eine weitere möglichkeit wäre es das regelmässig z.b. ein mal am tag zu machen. z.b. immer wenn ds ding aufwacht und auf anfragen wartet.

gruss
  andre

[fidel]

Hi,

nur zur Info habe den PanStamp an der 7390 zum laufen bekommen, indem ich den hinteren USB Anschluss genommen habe!?!?!
Und in der Fritzbox den USB Ferngeräte-Anschluss deaktiviert habe.
Am seitlichen Anschluss wurde er laut lsusb nicht erkannt.
Der ftdi_sio Treiber ist auf der Box schon vorhanden.


Grüße

[Tobias]

ich habe hier ein Notify welches auf *.:battery laucht und mir eine Mail schickt wenn ein Reading <> ok lautet.
Es würde also etwas bringen wenn das SWAP-Modul ein Reading "battery" bereitstellt. 2 Schwellwerte hört sich noch besser an ;)
Ich denke die angepassten Sketche für den jeweiligen Anwendungsfall sind schon eine gute Sache. Für Speziallösungen muss man dann den bininp-Sketch nutzen.

Bzgl. Datensicherung im eeprom: Mir persönlich reicht es wenn es auf der ToDo Liste der nächsten BatteryBoard-VErsion steht. Da wo ich z.Z. PulseCounter benötige habe ich 1Wire zu liegen.

So nebenbei beobachte ich hier die Readings und Updates derer. Mir fallen die unterschiedlichen Timestamps auf. Kann das sein, das der panstamp im angegebenen Intervall, aber nur die die Änderung sendet? Oder ist noch etwas bei mir falsch konfiguriert? Ich habe noch keine Sensoren angeschlossen, deshalb dieser niedrige Wert.
(siehe Anhang / see attachement)
Im übrigen: VWC heißt VolumetricWaterContent (danke an pah für die Formel) und gibt die Bodenfeuchte bei Nutzung der Vegetronix VH400 Sensoren in % an.

Code: [Auswählen]

VWC_A:0C.0-Moisture_level_0 {sprintf("%.0f",(11.6552 * (hex(ReadingsVal($name," 0C.0-Moisture_level_0","0"))*0.001)**4 + 7.10835 * (hex(ReadingsVal($name," 0C.0-Moisture_level_0","0"))*0.001)**2 - 0.569557) / ((hex(ReadingsVal($name," 0C.0-Moisture_level_0","0"))*0.001)**2 + 1))}

[Tobias]

Stimmt eigentlich die Verdrahtungsanleitung mit den im Sketch angegebenen Pins überein?

Code: [Auswählen]

#define SENSOR_0_PIN  3     // Analog pin - sensor 0
#define POWER_0_PIN   16    // Digital pin used to powwer sensor 0
#define SENSOR_1_PIN  5     // Analog pin - sensor 1
#define POWER_1_PIN   18    // Digital pin used to powwer sensor 1

Ich will pro Panstamp nur Sensor0 nutzen. Sensor1 bleibt frei

Ich hänge gerade beim Verständnis der der Pin-Konventionen.
Laut Anleitung ist der Sensor an A4/A5 abgeschlossen. Man sieht hier, das A4/A5 = PC4/PC5 bzw Pin 9/10 ist. Wie zum Kuckuk kommt man dann im Sketch auf "#define SENSOR_0_PIN  3"??
Und was ist Pin 16/18? Es gibt auf dem BatteryBoard nur A0 bis A5 und D3 bis D9

[justme1968]

die readings 0B und 0C sind falsch. wenn kein register name dabei steht fehlt das ProductCode Attribut. hattest du nach dem setzten gespeichert?

die userReadings die automatisch angelegt werden gehen jeweils auf den kompletten namen (id-name).

bitte setze mal das attribut ProductCode auf 000000010000000E und lösche danach die beiden readings 0B und 0C. wenn das nicht hilft schick mir bitte mal ein list vom device.


wenn alles passt (readings mit id und namen und die dazugehörigen userReadings) sollten die timestamps gleich sein.


was die pins angeht muss ich heute abend zuhause in ruhe nachschauen.

gruss
  andre

[justme1968]

ich habe gleich eine version des swap moduls fertig die automatisch das default sende intervall auf eine stunde setzt wenn es noch der default ist und versucht eine freie adresse in einem vorgegebenen zu setzten falls es noch die default adresse ff ist.

magst du das probieren wenn ich es fertig getestet habe? meinst du weniger als eine stunde ist besser?

gruss
  andre

edit: falls du es testen willst hab ich mal die neue version angehängt. der timeout wird nicht mehr auf eine stunde sondern 15 minuten (0384 = 900 sekunden) gesetzt.

[Tobias]

Hi,
klar teste ich es... muss eben noch schnell die restlichen panstamps eine Antenne anlöten und dann gehts los...
Hast du ev. schon was bzgl dem Pin-Mapping rausbekommen?

[justme1968]

rausgefunden noch nicht. aber mir ist wieder eingefallen das ich das gleiche problem hatte.

ich habe dann bei meinem test die beiden pins einfach auf etwas gesetzt das mir logisch erschien.

sobald ich an den rechner komme sag ich dir genaueres.

[Tobias]

So, getestet... leider nicht ganz. per Autocreate wurde zwar ein Device SWAP_A0 angelegt, die addr bzw DeviceAddr blieb FF, auch das SendeIntervall blieb auf FFFF. Musste wieder abbrechen und manuell A0 setzen.
Jetzt hab ich noch 2 unbenutzte Panstamps um zu testen.

kurze Frage, Beim autocreate wird das Device mit einer Definition: FF 000000010000000E
angelegt, wozu dann noch das Attr ProductCode?

[justme1968]

arg... das kommt davon wenn man auf dem trockenen testet. anbei noch mal eine version mit der es bei mir mit drei panstamps funktioniert hat. die automatisch vergebenen adressen sind im bereich F0-FE. d.h. eigentlich auch nur temporär und sollten auf eine lokal passende geändert werden. im log sollte etwas in der art auftauchen:

Code: [Auswählen]

2013.07.29 20:14:29 3: SWAP Unknown device FF, please define it
2013.07.29 20:14:29 2: autocreate: define SWAP_F0 SWAP FF 000000010000000E
2013.07.29 20:14:29 3: SWAP_F0: I/O device is panStamp
2013.07.29 20:14:29 3: SWAP SWAP_F0: changing 09-DeviceAddress from default FF to F0
2013.07.29 20:14:30 3: SWAP SWAP_F0: changing 0A-PeriodicTxInterval from default FFFF to 0384 (900 seconds)

2013.07.29 20:16:35 3: SWAP Unknown device FF, please define it
2013.07.29 20:16:35 2: autocreate: define SWAP_F1 SWAP_0000002200000003 FF 0000002200000003
2013.07.29 20:16:35 3: SWAP_F1: I/O device is panStamp
2013.07.29 20:16:36 3: SWAP SWAP_F1: changing 09-DeviceAddress from default FF to F1
das ganze hat hmmm historische gründe :) am anfang gab es nur das attribut. wie autocreate funktioniert hab ich erst später rausgefunden. aus dem code heraus ist es aber einfacher auf das attribut zuzugreifen. also wird das attribut jetzt eigentlich automatisch gesetzt wenn es in der definition da war. es gab aber bis eben einen fehler das es beim ändern der adresse wieder aud dem def verschwindet. das habe ich eben gefixt.

ich hab dir auch noch eine etwas geänderte version vom soilmoisture.ino angehängt. die geht etwa alle 12 stunden in den sync mode und wartet für 3 sekunden auf kommandos.

gruss
  andre

[Tobias]

Hi Andre,
komme morgen Abend wieder dazu die panstamps zu flashen.
Wollte heute Abend noch dem BatteryBoad 2x 3-polige Anreihklemmen verpassen, musste aber mit Schrecken feststellen das meine mit Rastermass 5mm  nicht passen.. grrrr
Mit dem Zollstock gemessen müsste es ein RM von 3.5mm sein. Was hast du für welche drauf?

Edit: wär schön wenn du zum Pin-Mapping was finden könntest

[fidel]

Hi,

ist es möglich im Sketch für das RGBDriver Board zu berücksichtigen, dass es nach dem Anschalten wieder den Zustand vor dem Einschalten annimmt?

Grüße

[justme1968]

das sollte schon gehen.

register 0E PowerOnState:
 - 1. byte: 0-> aus, 1-> weiss, 2-> eine bestimmte farbe, 3 -> autosave
 - 2. byte: helligkeit
 - 3-5. byte rrggbb

du kannst z.b. mit  'set <device> regSet 0E 0200FFFFFF' einstellen das nach dem einschalten alle drei farbkanäle voll aufgedreht werden.

oder mit 'set <device> regSet 0E 0300000000' autosave aktivieren. dann wird jeweils nach 5 minuten ohne änderung die aktuelle farbe ins eeprom gesichert. die 5 minuten könnte man eventuell noch verkürzen.

für autosave ist am anfang der loop das schreiben ins eeprom zu aktivieren (das '#if 0' in ein #'if 1' ändern). an dieser stelle kannst du auch die 5 minuten anpassen.

wenn ich die erweiterung auf 4 bzw. 5 kanäle fertig habe stelle ich die neue version  hier rein. dann wir das alles auch ein bischen einfacher zu konfigurueren sein.

gruss
  andre

[justme1968]

so...

zum einen ist das bildchen natürlich falsch: der grüne vom oberen sensor auf dem bild sollte nach a3 und nicht nach a4 wenn es zum sketch passen soll,  zum anderen sind die 16 und 18 für die digital pins falsch. es muss 7 und 6 sein.


wenn es also zum bild passen soll muss es so aussehen:

#define SENSOR_0_PIN  4     // Analog pin - sensor 0
#define POWER_0_PIN   7     // Digital pin used to powwer sensor 0
#define SENSOR_1_PIN  5     // Analog pin - sensor 1
#define POWER_1_PIN   6     // Digital pin used to powwer sensor 1

gruss
  andre