hcan4mqtt nur für bananapi

[Thomas]

Ich hab heute versucht die hcan4mqtt zum Laufen zu bringen. Leider bin ich dabei nicht von Erfolg gekrönt worden. Offensichtlich können keine Daten zum CAN Bus gesendet werden. Nun hab ich mich etwas im Sourcecode versucht. Meine Vermutung ist nun, die beiden Programmeteile hcan4mqttc und hcan4mqttpc sind nur für den bananapi geschrieben und verwenden den onboard CAN device. Ich wollte das ganze über einen raspberry und einen über USB angeschlossenes hostinterface betreiben.

Kann mir das jemand bestätigen?

VG und danke...
Thomas

[hcaningo]

Hallo Thomas,
wenn du z.B. hcan4mqttpc verwenden möchtest, dann ist deine Schnittstelle socketCAN. Diese ist auf dem jeweiligen Linux einzurichten. Daher ist jede Hardware/Softwarekonstellation ohne Anpassung des hcan4mqttpc möglich, wenn diese socketCAN unterstützt.

Zusätzlicher Hinweis: hcan4mqttpc (socketCAN) löst hcan4mqttc (can4Linux basierend) ab.

Viele Grüße,
Ingo

[Michael Graf]

Moin,

ich versuche mich auch seid einigen Tagen an hcan4mqtt. Den socketCAN habe ich am laufen, aber wie kann ich jetzt über hcan4mqttpc eine Nachricht absetzen oder empfangen?

Mosquitto läuft erfolgreich auf einem anderen Rechner, die IP habe ich in der main.c eingetragen.

Mein Ziel ist die Integration von OpenHab2.

Danke für die Hilfe.

Michael

[hcaningo]

siehe hier: openHCAN/hcanhab2_mqtt/MqttSchnittstelle.txt

per MQTTlens kann getestet werden.

Die Passworterstellung für den MQTT-Broker ist hier vorbereitet: openHCAN/pi/Systemd/

@ openHCAN/hcan4mqttpc/mqttClient.c ist es direkt eingetragen. Das sollte künftig verbessert werden.

Viele Grüße,

Ingo

[Michael Graf]

Moin,

erstmal Danke für die Hinweise. Ich bin jetzt auch schon ein ganzes Stück weiter.

Allerdings bekomme ich immer eine Fehlermeldung. Hab es jetzt schon auf drei Systemen versucht.

nadors@HCAN:~/openHCAN/hcan4mqttpc$ ./hcan4mqttpc -D -c 192.168.2.113 -d can0

MQTT-Broker-Host-IP: 192.168.2.113

serial can device: can0

initMQTT: connect to broker=192.168.2.113, port=1883

broker_connected -> subscribe (Nachrichten zum CAN-Bus)

:) got SUBACK: (QoS=0)

can0 at index 4

Speicherzugriffsfehler (Speicherabzug geschrieben)

Der can0 läuft, zumindest kann ich mit "candump can0"  Nachrichten auf dem Bus verfolgen.

Schöne Grüße

Michael

[Michael Graf]

Moin,

eventuell Hilft das hier weiter. An dieser Stelle bin ich mit meinem Latein am Ende

(gdb) run file hcan4mqttpc -D

The program being debugged has been started already.

Start it from the beginning? (y or n) y

`/home/nadors/openHCAN/hcan4mqttpc/hcan4mqttpc' has changed; re-reading symbols.

Starting program: /home/nadors/openHCAN/hcan4mqttpc/hcan4mqttpc file hcan4mqttpc -D

initMQTT: connect to broker=192.168.2.113, port=1883

broker_connected -> subscribe (Nachrichten zum CAN-Bus)

:) got SUBACK: (QoS=0)

can0 at index 4

Program received signal SIGSEGV, Segmentation fault.

strtok () at ../sysdeps/i386/i686/strtok.S:212

212     ../sysdeps/i386/i686/strtok.S: Datei oder Verzeichnis nicht gefunden.

(gdb) backtrace

#0  strtok () at ../sysdeps/i386/i686/strtok.S:212

#1  0x0804979a in getMessage4cb (msg=0x804ad26 "RQ", msg4cb=0x0) at mqttHcan.c:38

#2  0x08049136 in createMsg4cb (msg=0x804ad26 "RQ") at mqttClient.c:140

#3  0x08048caf in main (argc=<optimized out>, argv=<optimized out>) at main.c:122

(gdb)

Schöne Grüße

Michael 

[hcaningo]

Hallo Michael,
im Github-Repro ist ein Patch hochgeladen. Ist das Problem nun gelöst?

Viele Grüße,
Ingo

[Michael Graf]

Hallo Ingo,

vielen lieben Dank für deine Mühe, grundsätzlich läuft es jetzt.

Allerdings läuft hcan4mqttpc immer nur für ein paar Minuten, dasselbe Problem hab ich mit hcansocketd. Was immer mal geht und dann wieder nicht.

Wobei ich mit candump über can0 zuverlässig den Bus beobachten kann.

Ich werde das mal weiter verfolgen.

Noch was anderes, wird das Hostinterface auch von SocketCAN unterstützt?

Schöne Grüße
Michael

[Michael Graf]

Ok, das Problem bei hcan4mqttpc ist eine CPU-Auslastung von 100% für den Prozess.

[hcaningo]

Hallo Michael,
freut mich!

hcansocketd ist die Hostinterface-Software. Welche Hardware bei dir zum Einsatz kommt, hast du noch nicht verraten. Aber diese HW + hcansocketd-SW bilden das Hostinterface.

Schöne Grüße,
Ingo

[Michael Graf]

Hallo Ingo,

Denkfehler von mir, ich dachte immer das Hostinterface ist die HW (Hostinterface-v02). Ich nutze einen USB/CAN Adapter, den ich mal aus dem Netz nachgebaut habe.

Hast du eine Idee woran es liegen kann, dass hcan4mqttpc nach kurzer Zeit eine CPU Auslastung von 100% hat und damit nicht mehr reagiert? Hab es schon auf verschiedenen Systemen getestet.

Ich bin schon am überlegen, ob ich den Prozess einfach jede Minuten neu starte. Keine schöne Lösung, schafft aber kurzfristig Abhilfe.

Schöne Grüße

Michael

[hcaningo]

an der USB-Verbindung?

[Michael Graf]

Hallo Ingo,

an der USB-Verbindung liegt es leider auch nicht. Selbst mit einem virtuellen CAN-Gerät, habe ich mit hcan4mqttpc, nach kurzer Zeit eine Auslastung der CPU von 100%.

Ich werde es jetzt noch mal mit älteren Versionen von Ubuntu testen. 

Benutzt du selber auch Ubuntu 17.04?

Schöne Grüße

Michael

[hcaningo]

Hallo Michael,
auf meinem Ubuntu 17.04 - 32 Bit compiliert alles und läuft auch telican, aber der hcan4mqttpc macht aus meiner Sicht dort keinen Sinn: Es ist mein Entwicklungslaptop, welcher ausgeschaltet wird und weder eine direkte CAN-Verbindung hat noch benötigt (geht ja über LAN/WLAN: z.B. telican -a ...).

hcan4mqttpc läuft (neben den anderen HCAN-Diensten) bei mir ausschließlich auf dem Bananapi unter dem aktuellen Armbian. Dort läuft dann auch noch der MQTT-Broker und auch openHAB.

Viele Grüße,
Ingo

[Michael Graf]

Hallo Ingo,

ich bin jetzt auch komplett auf den Bananapi umgestiegen. Ich werde ihn jetzt noch in die Verteilung setzen, dann kann er da seinen Dienst vollrichten.

Die HCAN-Dienste laufen alle, alle bis auf hcan4mqtt. Ich weiß jetzt echt nicht mehr weiter. Irgendwas muss ich grundsätzlich falsch machen.

Hast du vielleicht noch eine Idee, was ich noch versuchen kann?

Schöne Grüße

Michael

[hcaningo]

Hallo Michael,
habe dem hcan4mqttpc noch einige Debug-Einträge hinzugefügt. Z.B. sollte bei der fast "100%-Auslastung" nun "selcet-timeout" sichtbar werden. Dazu manuell mit Debug starten: "hcan4mqttpc -D".

Schau mal, wann genau sich der Dienst verabschiedet. Einen Versuchsaufbau-CAN-Bus, an dem z.B. nur zwei Lampen hängen, habe ich aktuell nicht verfügbar (kann das Problem bisher nicht nachstellen).

Viele Grüße,
Ingo

[Michael Graf]

Hallo Ingo,

die Ausgabe "select-timeout" erscheint ca. alle 0,5 Sekunden, nachdem ich hcan4mqttpc gestartet habe. Also schon weit vor der 100%-Auslastung und wird nur kurz für eine Sekunde unterbrochen, sobald hcan4mqttpc was zu tun hat.

...
select-timeout
select-timeout
select-timeout
cb> mqtt 102/OFF
select-timeout
select-timeout
select-timeout
....

Schöne Grüße

Michael

[hcaningo]

Hallo Michael,
solange keine Daten vorliegen ist das "select-timeout" alle 0,5 s genau richtig. Habe es auf 2,5 s erhöht. Kannst du damit nochmal prüfen.

Ein kontinuierliches "select-timeout" kann mit Trennen der CAN-Leitung erzeugt werden. Mit wieder Herstellen der CAN-Verbindung beendet sich dann der hcan4mqttpc. Mir stellt sich die Frage, woran zuverlässig ein Trennen und wieder Herstellen der CAN-Verbindung erkannt werden könnte. Dann wäre eine Debugausgabe und ggf. bessere Reaktion möglich.
 
Aber zurück zu deinem Problem: Ist dein CAN-Bus korrekt aufgebaut (Topologie beachtet/Terminierung mit 120 Ohm)? Aber, per telican kannst du Controller flashen und konfigurieren?

Viele Grüße,
Ingo

[Michael Graf]

Hallo Ingo,

also "select-timeout" kommt jetzt, wie von der beschrieben, alle 2,5 Sekunden. Ansonsten ist das verhalten gleich.

Nach den besagten 32 Sekunden, bleibt die Debugausgabe mit "select-timeout" stehen. Drücke ich dann auf einen Lichtschalter, kommt noch eine Ausgabe "cb> mqtt ..." (Licht schaltet) und beim erneuten drücken (Licht schaltet) wird der Prozess ohne Ausgabe beendet.

Ein ähnliches verhalten fällt mir auch bei telican auf. Ohne eine Aktivität auf dem CAN-Bus, bekomme ich keine Verbindung mit "telican -c .." Drücke ich einmal kurz einen beliebigen Lichtschalter (Aktivität auf dem CAN-Bus), kann ich mich danach direkt mit telican -c verbinden. Danach kann ich dann auch flashen und konfigurieren, wobei telican -d immer funktioniert. Die Topologie und Terminierung habe ich beachtet, die gesamte Beleuchtung und alle Rolladen im Haus werden hier ohne jegliche Probleme geschaltet.

Ich habe für mich das Problem jetzt erstmal so gelöst, dass ich alle 10 Sekunden eine Temperatur sende. Mit Aktivität auf dem CAN-Bus, laufen hcan4mqtt und telican dann problemlos.

Bei Gelegenheit werde ich noch mal einen minimalen aufbau testen um Fehler in der Topologie auszuschließen. Aber eigentlich funktioniert ja sonst soweit alles problemlos.

Wenn ich noch was testen soll, dann immer her damit. Muss ja nur die Temperatur ausstellen. ;-)

Schöne Grüße

Michael

[hcaningo]

Hallo Michael,
habe das "Problem" gefunden und eine Lösung ins git gestellt (hcan4mqttpc). Bitte noch einmal testen.

Stimmt, die Temperaturergbnisse sorgen auch hier kontinuierlich für Nachrichten zum MQTT-Broker.


Gibt es bei "telican -c .." tatsächlich ein ähnliches Verhalten?

Viele Grüße,
Ingo

[Michael Graf]

Hallo Ingo,

es scheint jetzt zu funktionieren. Ohne kontinuierliche Nachrichten zum MQTT-Broker, sieht die Ausgabe dann wie folgt aus;

select-timeout

select-timeout

mqttRead: rc=-1

initMQTT: connect to broker=localhost, port=1883

broker_connected -> subscribe (Nachrichten zum CAN-Bus)

:) got SUBACK: (QoS=0)

select-rtn=1 0x10

select-timeout

select-timeout

Zum Verhalten bei "telican -c ..", hier beobachte ich in der Tat ähnliches.

nadors@bananapi:~/myOpenHabInstallation/conf/sitemaps$ telican -c 200

transport connection error: timeout while waiting for packet

nadors@bananapi:~/myOpenHabInstallation/conf/sitemaps$ candump can0

 can0  00108CC8   [4]  05 01 02 01

 can0  031090C8   [4]  05 11 66 00

 can0  00108CC8   [4]  05 02 02 01

^Cnadors@bananapi:~/myOpenHabInstallation/conf/sitemaps$ telican -c 200

>

Bei längerer Zeit ohne Aktivität auf dem CAN-Bus, bekomme ich keine Verbindung. Einmal kurz für Daten sorgen und alles läuft wie es soll.

Schöne Grüße

Michael

[hcaningo]

Hallo Michael,
zum ersten Punkt: Ja genau, so ist es gewollt.
Den zweiten Punkt werde ich bei Gelegenheit genauer ansehen. Danke für deinen Hinweis.

Viele Grüße,
Ingo

[hcaningo]

Hallo Michael,
Punkt 2 bin ich nun auch angegangen. Wenn du magst, kannst du es unter Nutzung von Debug-Ausgaben einmal testen!?

Viele Grüße,
Ingo

[Manuel Oswald]

Hallo Zusammen Ich wollte mich mal an euren Thead dranhängen .

Bei mir läuft es leider fast genauso .

Nur habe ich das Problem das hcan4mqtt nichts empfängt und nichts sendet .

127 root@bananapi ~ # hcan4mqttpc -D -c 192.168.188.27 -d can0                                                                                                                                    :(

MQTT-Broker-Host-IP: 192.168.188.27

serial can device: can0

initMQTT: connect to broker=192.168.188.27, port=1883

broker_connected -> subscribe (Nachrichten zum CAN-Bus)

:) got SUBACK: (QoS=0)

can0 at index 0

hcan4mqttpc[1556]: could not send complete CAN packet: written=-1, data-size=2!

select-rtn=1 0x2

select-timeout

select-timeout

select-timeout

select-timeout

select-timeout

select-timeout

select-timeout

select-timeout

select-timeout

Seltsamerweise funktioniert Telican ohne Probleme ,ich kann auch die Controller Programmieren und mit  dem Telican Controll Modus steuern .

wenn ich das Dump öffne geht es auch .

130 root@bananapi ~ # telican -d -a 127.0.0.1                                                                                                                                                     :(

IP address : 127.0.0.1

 0200 -> 0036 :SFP HES 1WIRE_TEMPERATURE gruppe:1 temp_hi:1 temp_lo:60

 0200 -> 0036 :SFP HES 1WIRE_TEMPERATURE gruppe:1 temp_hi:1 temp_lo:60

 0200 -> 0035 :SFP HES TASTER_DOWN gruppe:1 index:0

 0200 -> 0036 :SFP HES POWER_GROUP_STATE_INFO gruppe:1 status:0

 0200 -> 0035 :SFP HES TASTER_UP gruppe:1 index:0

 0200 -> 0035 :SFP HES TASTER_DOWN gruppe:1 index:0

 0200 -> 0036 :SFP HES POWER_GROUP_STATE_INFO gruppe:1 status:1

 0200 -> 0035 :SFP HES TASTER_UP gruppe:1 index:0

 0200 -> 0035 :SFP HES TASTER_DOWN gruppe:1 index:0

 0200 -> 0036 :SFP HES POWER_GROUP_STATE_INFO gruppe:1 status:0

 0200 -> 0035 :SFP HES TASTER_UP gruppe:1 index:0

 0200 -> 0036 :SFP HES 1WIRE_TEMPERATURE gruppe:1 temp_hi:1 temp_lo:60

 0200 -> 0035 :SFP HES TASTER_DOWN gruppe:1 index:0

 0200 -> 0036 :SFP HES POWER_GROUP_STATE_INFO gruppe:1 status:1

 0200 -> 0035 :SFP HES TASTER_UP gruppe:1 index:0

 0200 -> 0035 :SFP HES TASTER_DOWN gruppe:1 index:0

 0200 -> 0036 :SFP HES POWER_GROUP_STATE_INFO gruppe:1 status:0

 0200 -> 0035 :SFP HES TASTER_UP gruppe:1 index:0

 0200 -> 0035 :SFP HES TASTER_DOWN gruppe:1 index:0

 0200 -> 0036 :SFP HES POWER_GROUP_STATE_INFO gruppe:1 status:1

 0200 -> 0035 :SFP HES TASTER_UP gruppe:1 index:0

 0200 -> 0035 :SFP HES TASTER_DOWN gruppe:1 index:0

 0200 -> 0036 :SFP HES POWER_GROUP_STATE_INFO gruppe:1 status:0

 0200 -> 0035 :SFP HES TASTER_UP gruppe:1 index:0

 0200 -> 0036 :SFP HES 1WIRE_TEMPERATURE gruppe:1 temp_hi:1 temp_lo:61

 0200 -> 0036 :SFP HES 1WIRE_TEMPERATURE gruppe:1 temp_hi:1 temp_lo:61

 0036 -> 0036 :SFP RTS TIME_INFO level:0 day_of_week:1 hour:21 minute:29 second:0

 0036 -> 0036 :SFP RTS DATE_INFO level:0 day_of_month:27 month_of_year:1 year:20

 0200 -> 0036 :SFP HES 1WIRE_TEMPERATURE gruppe:1 temp_hi:1 temp_lo:61

 0200 -> 0036 :SFP HES 1WIRE_TEMPERATURE gruppe:1 temp_hi:1 temp_lo:61

Aber irgend wie erscheint nichts auf dem Bus.

Mein verdacht das es eventuell meine installation.xml ist konnte mir noch keiner genau sagen .

<haus>

        <board addr="200">

                <tempsensor gruppe="1" name="Kind" />

                <taster gruppe="1" name="Lichttaster_Kind" />

                <powerport gruppe="1" name="Deckenlampe_Kind" typ="lampe" />

        </board>

</haus>

Vielleicht weiß jemand Rat .Wäre klasse Gruß Manuel Oswald