smarthome.py - mehrere onewire Server

[smokyat]

Hallo,

hat jemand schon Erfahrung mit der Einbindung von mehreren
onewire Server in das smarthome.py?

Habe versucht im plugin mehrere [ow] zu deffinieren,
leider ohne erfolg.

Lg
Klaus

[pfischi]

Hallo,

hat jemand schon Erfahrung mit der Einbindung von mehreren
onewire Server in das smarthome.py?

Habe versucht im plugin mehrere [ow] zu deffinieren,
leider ohne erfolg.

Lg
Klaus

Poste doch mal deine plugins.conf

[Robert]

Habe versucht im plugin mehrere [ow] zu deffinieren,
leider ohne erfolg.

Das sollte ja auch in einer tieferen Schicht erledigt werden:

OWSERVER(1) manual page - Parameter -s auf einem der Geräte sammelt die anderen ein - siehe auch Beschreibung.

Grüße
Robert

[smokyat]

Das sollte ja auch in einer tieferen Schicht erledigt werden:

OWSERVER(1) manual page - Parameter -s auf einem der Geräte sammelt die anderen ein - siehe auch Beschreibung.

Grüße
Robert

Hallo,

Definition:
Server: der, der die Geräte sammelt, Option -s
Client: der, der Geräte angeschlossen hat

das Problem mit dem -s ist, dass wenn der Server neu startet und der Client gerade nicht online ist, das der Client nie wieder erkannt.

Außerdem ist mir schon aufgefallen, auch wenn alle Clients online sind
kann es passieren, dass sie vom Server nicht erkannt werden.

Jetzt war meine Überlegung:
1. den smarthome.py meherer Clients eintragen
2. ein eigenes Plugin schreiben, das mit python-ow die Daten der
Clients holt.

plugin.conf:

[ow1]
class_name = OneWire
class_path = plugins.onewire
host = 172.16.1.189
# port = 4304

[ow2]
class_name = OneWire
class_path = plugins.onewire
host = 172.16.1.184

smarthome.log:

2014-02-02 08:52:02,717 INFO Connections 1-Wire: connected to 172.16.1.189:4304 -- __init__.py:connect:66
2014-02-02 08:52:02,969 INFO Connections 1-Wire: connected to 172.16.1.184:4304 -- __init__.py:connect:66
2014-02-02 08:52:03,150 DEBUG Connections WebSocket: binding to 0.0.0.0:2424 (TCP) -- connection.py:connect:160
2014-02-02 08:52:04,595 DEBUG Scheduler 1w-disc next time: 2014-02-02 09:02:04+01:00 -- scheduler.py:_next_time:289
2014-02-02 08:52:05,310 INFO 1w-disc 1-Wire: 28.DEB91B030000 with sensors: T11, T10, T, T12, T9 -- __init__.py:_discovery:431
2014-02-02 08:52:05,488 INFO 1w-disc 1-Wire: 28.A37BDE030000 with sensors: T11, T10, T, T12, T9 -- __init__.py:_discovery:431
2014-02-02 08:52:05,629 INFO 1w-disc 1-Wire: 3A.330E08000000 with sensors: IA, IB, OB, OA -- __init__.py:_discovery:431
2014-02-02 08:52:06,451 DEBUG 1w-disc 1-Wire: sensor 26.8B6001000000 voltage: 4.98 -- __init__.py:identify_sensor:200
2014-02-02 08:52:06,452 INFO 1w-disc 1-Wire: 26.8B6001000000 with sensors: V -- __init__.py:_discovery:431
2014-02-02 08:52:07,351 DEBUG 1w-disc 1-Wire: sensor 26.174D3F000000 voltage: 4.96 -- __init__.py:identify_sensor:200
2014-02-02 08:52:07,353 INFO 1w-disc 1-Wire: 26.174D3F000000 with sensors: VDD, H, T, L -- __init__.py:_discovery:431
2014-02-02 08:52:07,507 INFO 1w-disc 1-Wire: 81.5FBD31000000 with sensors: BM -- __init__.py:_discovery:431

sieht so aus, als ob er beide Clients läd, es werden aber nur die Sensoren vom 2. eingetragenen Client erkannt.

Lg
Klaus

[Robert]

Schätze mal dass über die Classpath etc einfach die erste Instanz von der zweiten "überfahren" wird. Den Connect schafft er noch, alles weitere geschieht schon nicht mehr. Dazu kann denke ich nur Markus mehr sagen.

Das der Server nicht beständig nach untergeordneten Servern sucht ist unschön, liegt aber in der Natur der Sache. Evtl. hier ein kleines Cron, was ggfl. den Server neu startet.

Grüße
Robert

[callidomus]

Hallo Klaus,

das geht momentan nicht.
Es steht momentan auch nicht auf der Roadmap. Sorry.

Bis bald

Marcus

[Sipple]

(temporäre?) Lösung

Hi

Hier mal ein konkretes Beispiel wie das Zusammenspiel von DREI mal Owserver mit SmartHome.py und smartVISU momentan klappt, ohne jetzt 1 Jahr Langzeiterfahrung zu haben und zu wissen, ob das halbwegs zuverlässig funktioniert. Sieht aber gut aus.

Ausgangssituation:

Rechner 1: ein altes ALIX1D mit Debian Squeeze (bei Wheezy will der I2C Bus ums Verrecken nicht funktionieren, trotz exakt gleicher Konfiguration). Am on-board I2C Anschluß hängt momentan Robert's VGA-IC2-8-fach-1-Wire-Adapter mit grad eben nur einem DS18S20. Owserver 2.9p5.

Rechner 2: ein Raspi mit Debian Wheezy und I2C-1-Wire-Adapter und daran grad 4 Feuchtesensoren und ein DS18S20. Owserver 2.9p5.

Rechner 3: ein Jetway NF36 mit Debian Wheezy, noch OHNE physikalischen 1-Wire Bus (kommt noch). Owserver 2.9p3. Darauf läuft SmartHome.py und smartVISU.

ALIX1D (IP 192.168.178.29):

root      1274     1  0 May23 ?        00:00:02 /usr/bin/owserver --usb=ALL --i2c=ALL:ALL --pid-file /var/run/owserver.pid

Raspi (IP 192.168.178.60):

admin     2053     1  0 May16 ?        00:07:28 /usr/bin/owserver --usb=ALL --i2c=ALL:ALL --pid-file /var/run/owserver.pid

JETWAY NF36 (IP 192.168.178.23):

root     25035     1  0 10:21 ?        00:00:00 /usr/bin/owserver --usb=ALL --i2c=ALL:ALL --server=192.168.178.60:4304 --server=192.168.178.29:4304 --pid-file /var/run/owserver.pid

Das Entscheidende ist also der owserver auf dem Jetway, der durch die ZWEI "--server=x.x.x.x:4304" Anweisungen die Sensoren von den anderen Rechnern mitbekommt (ja, man kann auch nur "-s" verwenden, sogar ohne "=").
Mehr braucht's da erst mal nicht.

plugin.conf auf dem JETWAY NF36:

[ow]
    class_name = OneWire
    class_path = plugins.onewire
#    host = 127.0.0.1
#    port = 4304

Das plugin verbindet sich also ausschließlich mit dem LOKALEN owserver des JETWAY NF36. Für die items und letztendlich die smartVISU ist das alles völlig transparent.

Wie gesagt, ob das auf die Dauer so tadellos funktioniert oder nicht, kann ich noch nicht sagen. Ich wollte mich auch mal daran machen, die wichtigsten Sachen per Monit oder sogar nagios zu überwachen. Aber da hatte ich den Nerv noch nicht dazu, für Lösungen wäre ich da aber sehr dankbar

Die Bilder zeigen das Ergebnis des owhttpd auf den jeweiligen Rechnern. (v.l.n.r: Raspi, ALIX1D, Jetway, smartVISU).

Gruß, Martin