Hi Folks,
ich nutze ein Arduino Uno mit FIRMATA um Analogwerte einzulesen. Das Device heisst FIRMATA und ist so deklariert:
define FIRMATA FRM /dev/ttyACM0@57600
Ebenfalls nutze ich einen JeeLinkv3:
define myJeeLink JeeLink /dev/ttyUSB0@57600
Nun habe ich heute einen CC1101 von busware bekommen, dazu habe ich den Arduino vom USB getrennt und den CC1101 angeschlossen, ihn mit CUL 1.67 geflasht. Das hat auf anhieb geklappt. Nachdem flashen war FHEM extrem langsam und ich finde folgende Zeilen im Logfile:
2017.10.26 18:16:43 3: no response from Firmata, closing DevIO
2017.10.26 18:16:43 1: /dev/ttyACM0 disconnected, waiting to reappear (FIRMATA)
2017.10.26 18:16:43 1: Perfmon: possible freeze starting at 18:16:39, delay is 4.152
2017.10.26 18:16:43 3: Setting FIRMATA serial parameters to 57600,8,N,1
Jemand eine Idee? Betreibt jemand FIRMATE und einen CUL-USB gleichzeitig?
ZitatJemand eine Idee?
Tipp der Woche im Wiki
https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden (https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden)
...für alle drei Geräte...
Sauber, danke für den Tipp. Wäre ich so nicht drauf gekommen. Hatte mich schon gewundert wie man sonst die USB-Devices auseinanderhällt: über die /dev/serial/by-id!
Vielen Dank, funktioniert
Notfalls geht auch by-path, wenn man versehentlich die falschen Nanos gekauft hat usw. (CH340G)...
Okay, danke für den Tipp!
Zitat von: MrJackBlack am 27 Oktober 2017, 07:30:13
Okay, danke für den Tipp!
Ist aber wirklich nur eine Notlösung. Besser ist es, bei der Beschaffung (bzw. beim Flashen, wo das möglich ist) darauf zu achten, dass man das auch wieder einfach auseinanderhalten kann. Diese Nanos (mit CH340G bzw. teilweise werden auch andere mcus damit ausgeliefert) sind daher nur solange ok, als man sie nicht an demselben Rechner betreiben will...
Einer geht aber.
Bis jetzt habe ich nur den CC1101 von busware.de und den Jeelinkv3 und einen Arduino. Mehr wird es wohl erstmal nicht. Eher weniger, da ich den Arduino wohl über 868MHz einbinden möchte. Muss da nur erstmal schauen ob via Jeelink oder Homematic-CUL (CC1101).
Ah, noch ein potentieller Selberbauer...
Meine Selbstbau-Sensoren habe ich über MySensors eingebunden, zwei meiner 5 USB-Geräte sind daher MySensors-GW's (RS485+nRF24).
Wenn es dich interessiert: Es gibt für Funk neben nRF (womit manche problematische Erfahrungen gemacht zu haben scheinen) auch die Option, RFM69 bzw. RFM95-Chips einzubinden (433 o. 868, RFM95 sollte sogar LoRa können). Da du Programmiererfahrung mitzubringen scheinst: Ist easy, kommt mir (als Programmier-Quereinsteiger) einfacher vor als Asksin++ und flexibler als Jeelink (ist nur one-way, wenn ich das richtig verstanden habe).
Viel Spaß jedenfalls,
Beta-User
Naja, sagen wir mal so: Programmieren könnte ich sicher schon, tue es auch ab und zu dort wo es notwendig ist, bin aber eher eine "faule Socke" und versuche es mir da eigentlich einfach zu machen. Liegt auch daran das ich nicht so viel Zeit habe um immer alles selber zu machen. Deswegen habe ich damals meine Erdsensoren (Temperatur und Feuchtigkeit) im Garten via FIRMATE eingebunden.
Das LoRa-Shiel hatte ich damals schon gefunden. Muss mich aber erstmal einlesen in die Thematik.
Meine Vorgabe ist das ich in Zukunft nur den JeeLink und den CC1101 im Einsatz habe. Noch einen Receiver möchte ich eigentlich nicht. Ich nutze einen RasPi1, der hat auch nur 2xUSB. Die Aussensensoren müssen also entweder via Lacrosse (Jeelink) oder als HM-Sensor eingebaut werden.
Na ja, "Programmieren" ist bei MySensors eigentlich auch relativ...
Man muß halt grundsätzlich wissen, was das mit before(), loop() usw. soll und dann noch ein paar Grundbegriffe kennen, dann geht das schon recht einfach. (Ich habe mich mit den MySensors-Beispielen erst in die C-Programmierung eingelesen. Brachte kaum mehr an Vorkenntnissen mit als das, was man vor 25 Jahren im Informatik-Unterricht gelernt hat ::) ).
Sobald man den ersten eigenen Multi-Sensor "programmiert" hat, geht das eigentlich flux... Und du kannst den Firmata-Arduino immer noch als Basis für ein LAN-GW nehmen oder einen ESP8266, wenn die USB-Anschlüsse ausgehen ;) . Ich glaube immer noch, dass das einfacher wäre, als die anderen beiden Varianten. Die Infos, die Firmata an FHEM gibt, müßtest du halt anders verpacken...
Habe mir wg. ausgegangener USB-Anschlüsse zwecks Eliminierung des USB-Hubs einen hp T5740 geholt (8 USB-Anschlüsse), da kann ich gut auf das Netzwerk-Gedöns verzichten. Ist halt eine Frage der Prioritäten-Setzung.
Mit dem ESP8266 über WiFi müsste ich schauen ob das ausreicht, da der Sensor recht weit weg vom Haus in den Boden kommt, also ins Beet :) Aus diesem Grund war mein erster Gedanke 868MHz, eventuell auch Batteriebetrieben, Solarpanel und einem Timer inkl. Relais, welcher alle x-Minuten die Sensorik einschaltet, sendet und sich wieder abschaltet. Soweit die Theorie ::)
Die Anzahl der USB-Ports ist in der Tat limitierend. Am Raspberry Pi 1 schätze ich vor allem das man quasi gezwungen ist FHEM zu optimieren. Man muss schon genau schauen wie oft man etwas abfragt, speichert und loggt. Ich habe noch einen IntelNUC (i5) rumliegen. Der war mal mein Media-Center. Bin aber wieder zurück zum Raspberry Pi 3 mit Kodi. Eventuell wird der NUC den FHEM-Raspberry Pi ablösen in naher Zukunft. Da habe ich auch mehr Luft nach oben für spätere Projekte.
Von den ESP8266 würde ich eigentlich gerne ganz abraten, habe (fast) nur schlechte Erfahrungen mit den Dingern (zufrieden scheinen nur die zu sein, die ESPeasy nutzen).
Die brauchen auch zu viel Strom für das bißchen Meßaufgabe und sind auch sonst zickig (persönliche Meinung). Aber man kann - wenn man unbedingt auf USB verzichten will und kein LAN-GW aufbauen - damit auch ein MySensors-GW aufbauen, zu dem dann der eigentliche Sensor sendet. Die Strecke wäre also
Sensor-Node <= 868/433MHz/2.4GHz => Gateway <= (W)LAN-Infrastruktur => FHEM-Rechner.
Mit Myensors@RFM95 ggf. in der ersten Strecke mit LoRa (aber niedriger Daten-Rate!). Oder eben einem seriellen GW (USB), dann fällt (W)LAN weg.
Soweit mir bekannt, sind RFM69-MySensors-Nutzer mit der Reichweite durchweg zufrieden.
Ansonsten: Ressourcen-optimiert zu arbeiten ist sicher eine gute Idee, aber man kann es auch ein bischen übertreiben ;) . Manchmal hilft es schon, ins log zu sehen und apptime usw. zu bemühen, um Probleme zu finden.
Die NUC-Nutzer scheinen jedenfalls in der Regel zufrieden mit ihrer Wahl zu sein. Wären immerhin 4 Ports (?), die HW liegt da und der Stromverbrauch scheint überschaubar zu sein.