Ethersex_Wiki - User contributions [en]

Protokolle duplizieren (Deutsch)

2012-07-26T04:46:07Z

Atos:

{{i18n|Protokolle duplizieren}}
= Protokolle duplizieren =
Es kommt immer mal wider vor, das man das gleiche Protokoll zweimal benötigt.

== Lösung 1 ==
Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestattet habe, der zwei UART besitz.
Diese zwei Schnittstellen wollte ich zum auslesen meiner Wechselrichter nutzen.

Das Protokoll der Wahl war bei mir sll (serial_line_log)

Leider muste ich feststellen, das ich immer nur ein Protokoll auf ein UART binden kann.
Da es bist jetzt noch keine gute Idee gibt, wie man so etwas besser lösen kann, hier ein kleiner Trick.
Das Protokoll serial_line_log wird einfach dupliziert. Ich habe jedes "seria_" in ein "serialzwei_" gewandelt.

* Kopieren des Ordners (cp -a ethersex/protocols/serial_line_log ethersex/protocols/serialzwei_line_log)
* alle Dateien im Ordner umbenannt (auser Makefile und config.in) (cd ethersex/protocols/serialzwei_line_log; mv serial_<...>.c serialzwei_<...>.c
* mit einem Editor Alle Variabeln und Symbolenamen geändert
<code>
vim serialzwei_line_log.c
:%s/SERIAL_/SERIALZWEI_/g
:%s/serial_/serialzwei_/g
:%s/sll_/sllzwei_/g
</code>
* in der serialzwei_line_log_ecmd.c muss noch der ecmd Befehl angepasst werden (ganz am Schluss der META abschnitt)
<code>
vim serialzwei_line_log_ecmd.c
:%s/sll get/sll2 get
:%s/sll_/sllzwei_/g
</code>
* in der protocols/serialzwei_line_log/config.in die Namen anpassen
<code>
vim config.in
:%s/LINE_/LINE2_/g
:%s/Line/Line2/g
</code>

* die ethersex/config.in und das MAKEFILE an die neuen Namen anpassen

Zum Schluss müssen noch zwei zentrale Dateien angepasst werden.

<code>
cd ethersex/
vim Makefile
SUBDIRS += protocols/serialzwei_line_log
</code>

<code>
vim config.in
source protocols/serialzwei_line_log/config.in
</code>

Danach sollte

<code>
make menuconfig
</code>

Jetzt sollte unter Protokolle das Serial Line Log zweimal vorhanden sein.

Anmerkung: Das gleiche Verfahren funktioniert auch mit dem yport-Protokoll. Wenn man z.B. einen ATMega644p besitzt und beide UARTs "gleichzeitig" benutzen will, kann man das yport-Protokoll mit dem hier vorgestellten Verfahren duplizieren. nc <ip> 7970 bzw nc <ip> 7971 liefert dann die Ausgabe der beiden Ports.

== Lösung 2 ==
Speziell für den U(S)ART gibt es eine elegantere Möglichkeit:

Die AVR-LIBC unterstützt inzwischen bis zu zwei U(S)ARTs durch verschiedene Makros. In den Dateien core/usart.h und scripts/usart-config.sh finden sich weitere hilfreiche Makros. Man geht wie folgt vor:

In config.in läßt man via menuconfig einen U(S)ART auswählen, indem man das Makro usart_choice() benutzt. Außerdem im Spiel sind die Makros get_usart_count und usart_count_used. Als Ergebnis sollten zwei Variable definiert sein: <mymodulename>_USE_USART und <mymodulename>_BAUDRATE, welche für die U(S)ART-Nummer bzw. die Baudrate stehen. Als Beispiel siehe YPort.

Im C-Quelltext benötigt man folgende Anweisungen:
* #define USE_USART <mymodulename>_USE_USART
Die Variable <mymodulename>_USE_USART muß in config.in auf eine Zahl 0 oder 1 für den ausgewählten U(S)ART gesetzt worden sein. Mit der Zuweisung an USE_USART versorgt man die folgenden universellen Makroaufrufe mit der richtigen U(S)ART-Nummer.
* #define BAUD <mymodulensme>_BAUDRATE
Gleiches Spiel für die Baudrate
* #include "core/usart.h"
Hier stehen Makros
* generate_usart_init()
Dieser Makroaufruf irgendwo im folgenden C-Quelltext generiert eine Routine usart_init() für den ausgewählten U(S)ART, setzt das Datenformat auf 8N1 und die Baudratenvorteiler auf den korrekten Wert. Außerdem werden die RXC und TX Interrupts freigegeben. Andere Datenformate als 8N1 sind (noch) nicht als Makro definiert, und wenn das Freigeben der Interrupts stört, dann sollte man anstelle des generate_usart_init() Makros die Intialisierung aller Register mit Hilfe der unten beschriebenen Makros selbst durchführen.
* ISR(usart(USART,_RX_vect)) bzw. ISR(usart(USART,_TX_vect)) etc.
So werden die Interrupthandler universell definiert, sie verwenden dann automatisch die richtige U(S)ART-Nummer.
* Die U(S)ART-Register sowie die Bit-Definitionen der Register werden ersetzt durch Makroaufrufe usart(<vordererTeil>[,<hintererTeil>]). Das Makro fügt die U(S)ART-Nummer ein.

[[Category:Development]]

Development/ECMD

2012-07-26T03:33:26Z

Atos: /* Parameters */

{{i18n|Development/ECMD}}
For general information on ECMD, see [[ECMD]].

The following variables will be used on this page. Replace them for your module.

* '''COMMAND''' - how the command will be invoked
* '''ARGUMENT1'''...'''ARGUMENTN''' - the arguments that will be passed together with '''COMMAND'''
* '''FUNCTIONNAME''' - the name of the function which will handle the command
* '''MODULENAME''' - the name of the module

= Preparations =

* Create a new file inside the folder of the module '''MODULENAME_ecmd.c'''
* Add this file to the [[Development/Makefile | Makefile]] of the module.
* Open the file and "#include "protocols/ecmd/ecmd-base.h" and other necessary headers.
* Add the header of the module, <string.h> etc.

= Create a new command =

Start with the following template:

<source lang="c">
int16_t parse_cmd_FUNCTIONNAME (char *cmd, char *output, uint16_t len)
{
/* Your Code here */
return ECMD_FINAL_OK;
}
</source>
Whenever '''COMMAND''' is invoked, this function will be called to handle it.

== Parameters ==

* *cmd holds '''ARGUMENT1'''...'''ARGUMENTN''' which have been passed along with the command. The command text you specified with ecmd_feature macro has already been stripped off, *cmd points to the arguments only. The length of the commandbuffer varies, and may not be zero-terminated properly.
* <strike>len is the length of the command (*cmd). Use this for securely parsing *cmd.</strike> len is the length of the output buffer. Do NOT write beyond this limit. Always check the remaining buffersize, or use snprintf_P with proper len param2. The output buffersize depends on the module that called the parser routine: UDP uses the remainder of the UIP buffer (first part of uip_buf holds the command), which is quite large. I2C uses ECMD_I2C_BUFFER_LEN, U(S)ART uses ECMD_SERIAL_USART_BUFFER_LEN and TCP uses ECMD_INPUTBUF_LENGTH (which is wrong, should be ECMD_OUTPUTBUF_LENGTH but both are equal and only 50 chars by default). If you have more text, use the ECMD_AGAIN return value: your routine will get called again in the next cycle. If your text should be continued on the same line, TCP has an ECMD_NO_NEWLINE mechanism at least for the first call, but other channels have not.
* *output is the output buffer <strike>which can hold 50 bytes/characters</strike>

== Return values ==
{| border="1"
| ECMD_FINAL_OK
| the command has been executed without any errors. "OK" will be written to the caller's output.
|-
| ECMD_FINAL('''len''')
| the command has been executed. '''len''' bytes of *output will be written to the caller's output
|-
| ECMD_AGAIN('''len''')
| the command has been executed but needs to be called again. '''len''' bytes of *output will be written to the caller's output
|-
| ECMD_ERR_PARSE_ERROR
| the command couldn't be executed (missing/wrong arguments etc.)
|-
| ECMD_ERR_READ_ERROR
| the command couldn't be executed (not able to read from device/hardware)
|-
| ECMD_ERR_WRITE_ERROR
| the command couldn't be executed (not able to write to device/hardware)
|}
== Announce the command ==

Append this to the bottom of '''MODULENAME_ecmd.c''' to let the ECMD parser know
about the new command.
<source lang="c">
/*
-- Ethersex META --
block(MODULENAME)
ecmd_feature(FUNCTIONNAME, "COMMAND", ARGUMENT1...ARGUMENTN , DESCRIPTION)
*/
</source>
The '''COMMAND''' along with the arguments and the description will show up [[ECMD_Reference | here]]

= Tips and best practice =

== Recursive calling a command handler function ==

If you need to output a lot of data (>50 bytes) , you need to recursivly call the command handler function
using '''ECMD_AGAIN()'''.

Instead of using unsafe ''static'' variables to keep track of the current progress you can use the following code:
<source lang="c">
/* trick: use bytes on cmd as "connection specific static variables" */
if (cmd[0] != 23) { /* indicator flag: real invocation: 0 */
cmd[0] = 23; /* continuing call: 23 */
cmd[1] = 0; /* local variable 1 */
}
</source>
[https://github.com/ethersex/ethersex/blob/master/protocols/ecmd/parser.c#L193 source]
[https://github.com/ethersex/ethersex/blob/master/services/dmx-storage/dmx_storage_ecmd.c#L105 example]
[[Category:Development]]

Onewire (Deutsch)

2012-07-26T02:37:34Z

Atos: /* Bezugsquellen */

{{i18n|Onewire}}

{{Module
|NAME=Onewire
|MENUCONFIG={{I/O}}->Onewire support
|STATUS={{stable}}
|PINNING=yes
|ECMD={{has_ecmd}}
|CONTROL6={{has_control6}}
|DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional)
|REQUIRES= -
|CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire]
}}

Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine
Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die
Temperatursensoren selbst.

= Pinning =

In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4
oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit:

<source lang=c>
ONEWIRE_PORT_RANGE(PXn, PXm)
</source>

wobei PXn und PNm Pins auf PORTX sind.

Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus.
Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!)

== Beispiele ==

Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt:

'''PORTD: PIN2'''
<source lang=c>
ONEWIRE_PORT_RANGE(PD2, PD2)
</source>

Für drei Busse würde das ganze etwa so aussehen:

'''PORTD: PIN2, PIN3, PIN4'''
<source lang=c>
ONEWIRE_PORT_RANGE(PD2, PD4)
</source>

= Polling Modus =

│ │ [*] Onewire Polling │ │
│ │ (375) Time between discoveries in 0.8s steps │ │
│ │ (12) Time between polling in 0.8s steps │ │
│ │ [*] ECMD 1w list with values │ │
│ │ (10) Maximum sensor count │ │

Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte
bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw.
eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen
den Abfragen der Werte kann getrennt eingestellt werden. Die Option
'''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte
bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende
'''1w get''' Kommandos entfallen.

Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss
per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher
reserviert wird.

= Benennung von Sensoren =

│ │ [*] Onewire naming support │ │
│ │ (10) Maximum sensor count │ │

Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM
eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden
bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es
folgende ECMD Kommandos:

1w name list

Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet
die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren
bei SNMP-Abfragen eindeutig zu referenzieren.

1w name set <ID> <ROM-Code> <Name>

Erstellt einen entsprechenden Tabelleneintrag.

1w name clear <ID>

Löscht die Felder eines Tabelleneintrags.

1w name save

Speichert die aktuelle Tabelle im EEPROM

= Unterstützte Hardware =

Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt:
* DS1820 (Temperatursensor)
* DS18B20 (Temperatursensor)
* DS1822 (Temperatursensor)
* DS2502 (EEPROM)
* DS2450 (4 Kanal ADC)

= Onewire Befehle =

unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren):

netcat 192.168.0.15 2701

danach am prompt:

1w list

Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus.
Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem
kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert
mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support
vorraus.

1w convert <hexcode>

Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode>
weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert.

1w get <hexcode>

Gibt die gemessene Temperatur eines Sensors aus.

= Einbindung in die [[HTTPD]]-Weboberfläche =

Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt
und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar
Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem
Onewiresupport den Webserver und das Datei Inlining aktivieren.

Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version
mit Naming-Support:

[[File:onewire-svg.png]]

= Anschluss AVR-NET-IO =
Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ ,

normal Betrieb

[[File:netio-1wire_normal.png]]

parasitären Modus

[[File:netio-1wire.png]]

Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der
Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V)
an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei
pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den
DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum
Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen.

Pinbelegung:

[[File:ds18s20-par-pinout.jpg]]

= Anschluss Etherrape =

Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden.
Data liegt auf PORTD an Pin 7:

PORTD
+---+
|x x|
|x X| <- Pin 7
|x x
|x x|
|x x|
+---+

Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung.
GND kann als GND und 5V als Vcc genutzt werden.

= Einbindung in [[Control6]] =

Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein
''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]].
Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10.
Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur
um mehr als ein Grad zur letzten Messung verändert hat.

<pre>
int16_t Temperatur;
int16_t Temperatur_alt;

CONTROL_START

THREAD(read_temp)
Temperatur = ONEWIRE_GET(10d85594010800eb);
ON abs(Temperatur-Temperatur_alt)>10 DO
div_t res = div(Temperatur,10);
SYSLOG("temperature changed %d.%d",res.quot,res.rem)
Temperatur_alt = Temperatur;
END
WAIT(15);
THREAD_END(read_temp)

ON STARTUP DO
Temperatur = Temperatur_alt = 0;
THREAD_START(read_temp);
END

CONTROL_END
</pre>

= Abfrage per [[SNMP]] =

Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden.
Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind
fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte
Sensoren über den SNMP-Index anzusprechen.

Es gibt folgende OIDs:

* .1.3.6.1.4.1.39967.3.1.<idx> : ROM-Code des Sensors
* .1.3.6.1.4.1.39967.3.2.<idx> : Sensor-Name (nur mit Naming-Support)
* .1.3.6.1.4.1.39967.3.3.<idx> : Temperaturwert in Centigrad
* .1.3.6.1.4.1.39967.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden

Hier ein Beispiel:

<pre>
# snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.39967.3
.1.3.6.1.4.1.39967.3.1.0 = STRING: "1080cff6010800f9"
.1.3.6.1.4.1.39967.3.1.1 = STRING: "10c8cff60108002d"
.1.3.6.1.4.1.39967.3.1.2 = STRING: "1029f6dc0108002f"
.1.3.6.1.4.1.39967.3.1.3 = STRING: "10f2d0f60108001c"
.1.3.6.1.4.1.39967.3.1.4 = STRING: "105a17f70108001d"
.1.3.6.1.4.1.39967.3.1.5 = STRING: "10b8d8f601080098"
.1.3.6.1.4.1.39967.3.1.6 = STRING: "104dedf601080057"
.1.3.6.1.4.1.39967.3.1.7 = STRING: "10011af701080027"
.1.3.6.1.4.1.39967.3.1.8 = STRING: "0000000000000000"
.1.3.6.1.4.1.39967.3.1.9 = STRING: "0000000000000000"
.1.3.6.1.4.1.39967.3.2.0 = STRING: "kessel"
.1.3.6.1.4.1.39967.3.2.1 = STRING: "warmwasser"
.1.3.6.1.4.1.39967.3.2.2 = STRING: "aussen"
.1.3.6.1.4.1.39967.3.2.3 = STRING: "speicher"
.1.3.6.1.4.1.39967.3.2.4 = STRING: "heizung vl"
.1.3.6.1.4.1.39967.3.2.5 = STRING: "heizung rl"
.1.3.6.1.4.1.39967.3.2.6 = STRING: "boiler vl"
.1.3.6.1.4.1.39967.3.2.7 = STRING: "boiler rl"
.1.3.6.1.4.1.39967.3.2.8 = ""
.1.3.6.1.4.1.39967.3.2.9 = ""
.1.3.6.1.4.1.39967.3.3.0 = INTEGER: 334
.1.3.6.1.4.1.39967.3.3.1 = INTEGER: 467
.1.3.6.1.4.1.39967.3.3.2 = INTEGER: 127
.1.3.6.1.4.1.39967.3.3.3 = INTEGER: 185
.1.3.6.1.4.1.39967.3.3.4 = INTEGER: 318
.1.3.6.1.4.1.39967.3.3.5 = INTEGER: 269
.1.3.6.1.4.1.39967.3.3.6 = INTEGER: 366
.1.3.6.1.4.1.39967.3.3.7 = INTEGER: 291
.1.3.6.1.4.1.39967.3.3.8 = INTEGER: 0
.1.3.6.1.4.1.39967.3.3.9 = INTEGER: 0
.1.3.6.1.4.1.39967.3.4.0 = INTEGER: 1
.1.3.6.1.4.1.39967.3.4.1 = INTEGER: 1
.1.3.6.1.4.1.39967.3.4.2 = INTEGER: 1
.1.3.6.1.4.1.39967.3.4.3 = INTEGER: 1
.1.3.6.1.4.1.39967.3.4.4 = INTEGER: 1
.1.3.6.1.4.1.39967.3.4.5 = INTEGER: 1
.1.3.6.1.4.1.39967.3.4.6 = INTEGER: 1
.1.3.6.1.4.1.39967.3.4.7 = INTEGER: 1
.1.3.6.1.4.1.39967.3.4.8 = INTEGER: 0
.1.3.6.1.4.1.39967.3.4.9 = INTEGER: 0
</pre>

= Codebeispiele =

* [[Onewire/Example/PHP (Deutsch) | PHP]]
* [[Onewire/Example/Perl (Deutsch) | Perl]]
* [[Onewire/Example/Python | Python]]
* [[Onewire/Example/Shell | sh/bash]]

[[Category:Ethersex]]
[[Category:StepByStep]]
[[Category:Onewire]]

= Bezugsquellen =
* Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de
* und natürlich bei den üblichen Verdächtigen: Reichelt, Segor, Conrad