Jump to content

CChris

Members
  • Gesamte Inhalte

    128
  • Benutzer seit

  • Letzter Besuch

CChris's Achievements

Apprentice

Apprentice (3/14)

  • Dedicated Rare
  • Collaborator Rare
  • First Post
  • Reacting Well Rare
  • Conversation Starter

Recent Badges

0

Reputation in der Community

  1. so, ich bin ein klein wenig weiter :) Die Auto-Erkennung funktioniert zwar noch nicht so zuverlässig, wie ich es gerne hätte ... das kann aber ggf. auch an meinem System liegen, da ich die Sensoren in HA entsprechend oft gelöscht und neu angelegt habe... Der nächste durchlauf wird daher mal mit einer "frischen" Datenbank sein ^^ Im Moment ist nur eine kleine Handvoll an alten Sensoren im Code umgesetzt... weitere werden folgen, diese kann ich aber mangels Hardware selber kaum testen. Für jeden Brick & jedes Bricklet wird ein eigenes "Device" in HomeAssistant angelegt Jedes Device ist dabei um die Information der UID - sowie, wenn vorhanden der UID des Bricks, an welches es angeschlossen ist benannt. Hier ist erkennbar, dass das Humidity Bricklet (eGQ), der MasterBrick (6qCxXx), das Temperature Bricklet (Temp2) und das Temperature IR Bricklet (zY2) jeweils am Master Brick (6m9VR4) angeschlossen sind. Diese Unterscheidung wird ggf. später notwendig, sollten mehrere eigenständige Stapel genutzt werden. Ob meine Software damit überhaupt umgehen kann, habe ich noch nicht getestet - der Fokus liegt im Moment nach wie vor auf einer rudimentären Funktionsweise... Jedes Device liefert informationen zur Installierten Firmware Version sowie der Hardware-Revision des Bricks / Bricklets. Ebenso werden die entsprechenden Sensor-Entitäten angelegt, wobei auch diese zur Identifizierung die UID mit im Namen tragen. Die Sensoren werden einmal bei der Enumerierung mittels .getXyz() abgerufen - danach über Callbacks, wenn sich der Wert ändert. Im Moment gibt es allerdings noch kleinere Probleme mit dem Sensor-Status direkt nach der Enumerierung... hier muss ich noch ein wenig arbeiten, da es ggf. notwendig ist, nach der Enumerierung den Stapel einmal zu resetten. Vermutlich irgend ein Timing Thema... ?! Eines der größten Probleme wird wohl sein, Aktoren hinzuzufügen. Mein Programm ist im Moment darauf ausgelegt, die Daten abzurufen und an HA zu schicken. Das funktioniert natürlich nicht, wenn eine eigene Programm-Logik vorhanden sein soll - oder aber, wenn aus HA heraus z.B. der Status eines Dual_Relay geändert werden soll... Hier wäre es zwar prinzipiell möglich, auf "eingehende" MQTT Nachrichten zu hören und dann entsprechende Aktionen auszuführen, da es sich aber stand jetzt noch nicht um eine eigene Integration für HomeAssistant handelt, können keine Steuerkomponenten hinzugefügt werden, welche das Automatisiert machen. Bei einer eigenständigen Integration würde sich auch der Umweg über MQTT erübrigen. Vielleicht gelingt es mir aber doch noch irgendwann, eine "halbwegs" brauchbare Integration zu machen...?
  2. a short progress - update :) So far, the Software seems to work as expected... It does enumerate through all devices connected to the master - and is using the callbacks for each sensor... Since I want to recognize all possible devices, I need to implement the code for each brick and bricklet hardware - which is a lot of "copy & paste" work, since I haven't yet found another way to do this... # every single device needs to be listed here... see imports for reference if enumeration_type == tf_main.IPConnection.ENUMERATION_TYPE_DISCONNECTED: return if device_identifier == tf_main.BrickDC.DEVICE_IDENTIFIER: # 11 device = tf_main.BrickDC(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) # nothing to do, since I don't have a DC Brick for testing elif device_identifier == tf_main.BrickMaster.DEVICE_IDENTIFIER: # 13 device = tf_main.BrickMaster(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) device.register_callback(device.CALLBACK_STACK_VOLTAGE, lambda *args: tf_callbacks.cb_stack_voltage(uid, *args)) device.set_stack_voltage_callback_period(int(config.get('TINKERFORGE', 'CallbackPeriod'))) device.register_callback(device.CALLBACK_STACK_CURRENT, lambda *args: tf_callbacks.cb_stack_current(uid, *args)) device.set_stack_current_callback_period(int(config.get('TINKERFORGE', 'CallbackPeriod'))) elif device_identifier == tf_main.BrickServo.DEVICE_IDENTIFIER: # 14 device = tf_main.BrickServo(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) # nothing to do, since I don't have a DC Brick for testing elif device_identifier == tf_main.BrickStepper.DEVICE_IDENTIFIER: # 15 device = tf_main.BrickStepper(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) # nothing to do, since I don't have a DC Brick for testing elif device_identifier == tf_main.BrickRED.DEVICE_IDENTIFIER: # 16 device = tf_main.BrickRED(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) ''' RED Brick is depricated, due to delivery issues for ICs. Replacements are HAT / HAT Zero as well as RaspberryPi compatible devices There are several options to controll the Software running on the RED Brick: example: start_program(program_id) -> to start a specific program on the RED Brick example: continue_program_schedule(program_id) example: get_program_schedule(program_id) example: set_program_schedule(program_id) ''' elif device_identifier == tf_main.BrickIMU.DEVICE_IDENTIFIER: # 17 device = tf_main.BrickIMU(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) # nothing to do, since I don't have a DC Brick for testing elif device_identifier == tf_main.BrickIMUV2.DEVICE_IDENTIFIER: # 18 device = tf_main.BrickIMUV2(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) # replacement for the IMU 1.0... ''' device.register_callback(device.CALLBACK_ALL_DATA) # <-- getting all data periodically device.register_callback(device.CALLBACK_ACCELERATION) # <-- getting only acceleration data device.register_callback(device.CALLBACK_ANGULAR_VELOCITY) # <-- getting only angular velocity data device.register_callback(device.CALLBACK_GRAVITY_VECTOR) # <-- getting only gravity data device.register_callback(device.CALLBACK_LINEAR_ACCELERATION) # <-- getting only linear acceleration data device.register_callback(device.CALLBACK_MAGNETIC_FIELD) # <-- getting only magnetic field data device.register_callback(device.CALLBACK_ORIENTATION) # <-- getting only orientation data device.register_callback(device.CALLBACK_QUATERNION) # <-- getting only quaternion data device.register_callback(device.CALLBACK_TEMPERATURE) # <-- getting only temperature data device.get_acceleration() # <-- getting acceleration data (could be required for init) device.get_orientation() # <-- getting orientation data (could be required for init) device.get_all_data() # <-- getting all data (could be required for init) ''' elif device_identifier == tf_main.BrickSilentStepper.DEVICE_IDENTIFIER: # 19 device = tf_main.BrickSilentStepper(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) ''' replacement for the Stepper Brick... but do we need Stepper-Information in HomeAssistant? we could get some information such as position-reached but probably it won't be possible to controll the stepper motor with this software / through HomeAssistant (maybe, we can set some "modes" like) set target position / set current position (?) / configure the step-resolution... etc. ''' elif device_identifier == tf_main.BrickletAmbientLight.DEVICE_IDENTIFIER: # 21 device = tf_main.BrickletAmbientLight(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) init_illuminance = device.get_illuminance() print("Current Illumination (init): " + str(init_illuminance / 10) + " lx") device.register_callback(device.CALLBACK_ILLUMINANCE, lambda *args: tf_callbacks.cb_illumination(uid, *args)) device.set_illuminance_callback_period(int(config.get('TINKERFORGE', 'CallbackPeriod'))) elif device_identifier == tf_main.BrickletCurrent12.DEVICE_IDENTIFIER: # 23 device = tf_main.BrickletCurrent12(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) elif device_identifier == tf_main.BrickletCurrent25.DEVICE_IDENTIFIER: # 24 device = tf_main.BrickletCurrent25(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) elif device_identifier == tf_main.BrickletDistanceIR.DEVICE_IDENTIFIER: # 25 device = tf_main.BrickletDistanceIR(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) elif device_identifier == tf_main.BrickletDualRelay.DEVICE_IDENTIFIER: # 26 device = tf_main.BrickletDualRelay(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) # nothing to do, since I don't have a DC Brick for testing elif device_identifier == tf_main.BrickletHumidity.DEVICE_IDENTIFIER: # 27 device = tf_main.BrickletHumidity(uid, tf_main.ipcon) device_work(device, device.DEVICE_DISPLAY_NAME, uid) init_humidity = device.get_humidity() print("Current Humidity (init): " + str(init_humidity / 10) + " %RH") device.register_callback(device.CALLBACK_HUMIDITY, lambda *args: tf_callbacks.cb_humidity(uid, *args)) device.set_humidity_callback_period(int(config.get('TINKERFORGE', 'CallbackPeriod'))) # and so on - for each device that COULD be connected... def device_work(device, device_display_name, uid): identifier = device.get_identity() hw_version = identifier[3] sw_version = identifier[4] print(f"{Fore.GREEN}Connected to: {device_display_name} {Fore.RED}{uid}{Style.RESET_ALL}") tf_log.log_output_info(f"connected to {device_display_name} - {identifier}") print("Hardware-Version (" + uid + "): " + write_version(hw_version)) print("Software-Version (" + uid + "): " + write_version(sw_version)) def write_version(version): version_no = str(version).replace(" ", "").replace("(", "").replace(")", "").replace(",",".") return version_no The Console-Output for this initialisation: after initializing and getting the current state of the sensors, I am calling the different callbacks for each device - so the states are being updated when the state does change: So - right now, I am working on the implementation to send these information over MQTT. Since I want to use the HomeAssistants MQTT Autodiscovery function, I can't use the MQTT Bindings directly... I have to change the topics and payload... a first static test was working so far... The MQTT integration has detected a new device - the Barometer Bricklet from tinkerforge. This device is creating the sensor "AirPressure" - and delivers the Firmware and Hardware-Information until now. I still need to implement the "State" Topic, so that the sensor will get the information ... and then, I need to change the code that this will be done dynamically for each device... So, still some work to do... and I am still not sure if I can implement a way to receive information from HomeAssistant, since it would be required that homeassistant does know to which topic something needs to be sent... so this would still be a lot of "manual configuration work" in HA... until I could MAYBE build some kind of integration which does create the entities and send the topics to the software. So, I think, this project can be somehow called a "brickviewer" for HomeAssistant (only viewer, atm)
  3. first tests of HomeAssistants Auto-Discovery are working... :) Now, I need to check, how to do that more dynamically during the program run-time and also publish the sensors state :D If my code is working so far, I'll try to see if I can redesign this in a way that it could also be used in other programs... or at least, I can create a small documentation on how this could be done...🤔
  4. Hi, Does anyone know, if the ESP32 Brick is working with ESPHome ? Before I would buy these brick for some tests, I would like to know, if anyone has already tried this... :)
  5. Hi @ngblume: ich habe mir die Sache mit der sich ändernden ID bei einem Batteriewechsel noch einmal durch den Kopf gehen lassen. Es ist zwar wirklich eine ziemlich doofe Sache - und ich verstehe nicht, warum das so umgesetzt wurde, aber Programmiertechnisch könnte man das ggf. abfangen... Das ist jetzt nur ein Theoretischer Ansatz - ich habe ihn selber noch nicht versucht... 1. aufbauen einer Verbindung zum "Outdoor-Weather-Bricklet" 2. ermitteln der erkannten IDs 3. Für jede erkannte ID wird programmtechnisch eine eigene ID generiert. 4. diese Infos werden in einer Liste o.ä. geschrieben - sodass man eine Zuordnung der Wetter-Stations-ID zu der eigens generierten ID hat. Nun gibt es m.E. drei Möglichkeiten: 1 - eine neue ID kommt hinzu, alle zuvor erkannten IDs sind noch vorhanden: -> es wird ein Eintrag in der Liste ergänzt. 2 - eine neue ID kommt hinzu, eine zuvor gespeichterte ist nicht mehr 'verbunden': -> in diesem Fall kann man davon ausgehen, dass sich die ID eines bereits bestehenden Gerätes durch z.B. einen Batteriewechsel geändert hat. Es wird daher ein Update auf den Listeneintrag der IDs gemacht ... die neue ID bekommt nun die eigene ID zugewiesen. 3 - eine ID wird nicht mehr gefunden, es kommt aber keine neue Hinzu: -> man lässt den Eintrag in der Liste bestehen, falls doch noch Fall 2 Eintritt... Wie gesagt, bisher nur Theoretisch... da ich selber keine Wetterstation im Einsatz habe - und selber aktuell nur ältere Bricklets meist aus der 1. Generation da habe... Aber meine Frau möchte ggf. tatsächlich so ein Teil noch haben, also könnte ich mich irgendwann demnächst mal genauer damit Außeinander setzen :D Allerdings frage ich mich gerade auch, ob das Weather-Bricklet NUR mit den hier verfügbaren Wetterstationen zurecht kommt, oder ggf. auch mit anderen Funk-Stationen, welche auf 433 MHz laufen? Weißt du da zufällig etwas?
  6. Hi, danke für die Info :) OK, ich habe keine Outdoor-Wetterstation zum testen da. Tatsächlich ist die Hardware, welche ich hier habe z.T. 10 Jahre alt und hatte bisher nur Staub angesammelt... daher die Idee, mit dieser jetzt vielleicht doch etwas 'sinnvolleres' anzustellen :) Ja, um das "Mapping" kommt man nicht drum herum, aber das ist letztendlich bei Tinkerforge so, wie bei allen anderen Geräten auch - wenn ich z.B. ein Thermostat von Homematik austausche, muss ich dieses auch erst in der CCU anlernen - umbennen - dann wird es in HomeAssistant erkannt & dann kann ich es zuweisen. ggf. muss ich es auch hier noch einmal umbenennen um nicht alle Automatisierungen abändern zu müssen. Da sehe ich (zumindest im Moment) - eigentlich keinen großen Unterschied. Ich habe mir jetzt aber tatsächlich mal die Dokumentation für das Outdoor-Weather Bricklet angeschaut... ... jetzt steht hier leider nicht, ob der Identifier auch bei einem Batteriewechsel erhalten bleibt oder nicht - wenn nicht, macht das ja eine programmbasierte Zuweisung egal für was deutlich schwerer... Auf der anderen Seite... wie viele Outdoor-Wetterstationen hat man i.d.R. daran angeschlossen? Maximal vielleicht die Temperatur/LF-Sensoren ... da könnten ggf. mehrere im Einsatz sein...🤔
  7. Hi, Ich versuche gerade ein Script zu schreiben, welches dann in der Lage sein soll, TF Bricks und Bricklets "dynamisch" auszulesen und Werte über den paho-mqtt client an einen Broker zu senden. Der Grund, warum ich diesen Weg gehe - und nicht direkt die MQTT Bindings von Tinkerforge nutzen möchte ist, dass ich eigentlich recht wenig Aufwand in die Konfiguration auf seiten HomeAssistant haben möchte. Ich möchte sämtliche Werte (erst einmal nur Sensoren einlesen und weiter geben) so strukturieren, dass sie über die Auto-Detection der MQTT integration erkannt werden und daraus dann direkt Sensoren generiert werden können. Dadurch spart man sich das händische Anpassen der Config, wenn es eine Änderung in der Hardware gegeben haben sollte. Später sollen, sofern ich das hinbekomme, auch Topics empfangen werden können, damit man auch aus HomeAssistant heraus "steuern" kann. Aktuell bin ich aber noch in einem sehr frühen Stadium... es wird also noch etwas Zeit brauchen, bis das ganze soweit sein wird...
  8. ok, I have made some first basic steps... this is still a very very basic python script for testing... # connection parameter HOST = "192.168.52.55" PORT = 4215 # these needs to be used dynamically later... # right now, they are only for testing BARO_1_UID = "vNB" BARO_2_UID = "vHa" from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_barometer import BrickletBarometer def cb_enumerate(uid, connected_uid, position, hardware_version, firmware_version, devic> # removed output for shorter code here def cb_air_pressure(air_pressure): # here, I would like to output from which bricklet the information came # since we do have two barometers connected, the output should somehow include the uid of the bricklet...? print("Air Pressure: " + str(air_pressure/1000.0) + " hPA") def cb_altitude(altitude): # here, I would like to output from which bricklet the information came # since we do have two barometers connected, the output should somehow include the uid of the bricklet...? print("Altitude: " + str(altitude/100.0) + " m") if __name__ == "__main__": ipcon = IPConnection() # Create IP connection # connect to the barometer bricklet(s) # if multiple devices with the same device-id are found, it should be done dynamically # f.e. for each barometer in barometers... something like that. b1 = BrickletBarometer(BARO_1_UID, ipcon) b2 = BrickletBarometer(BARO_2_UID, ipcon) ipcon.connect(HOST, PORT) # Connect to brickd or to network attached device ipcon.register_callback(IPConnection.CALLBACK_ENUMERATE, cb_enumerate) ipcon.enumerate() # register the callback(s) and set the callback period(s) for the barometer bricklet(s) # if multiple devices with the same device-id are found it should be done dynamically # f.e. for each barometer in barometers... something like that b1.register_callback(b1.CALLBACK_AIR_PRESSURE, cb_air_pressure) b2.register_callback(b2.CALLBACK_AIR_PRESSURE, cb_air_pressure) b1.register_callback(b1.CALLBACK_ALTITUDE, cb_altitude) b2.register_callback(b2.CALLBACK_ALTITUDE, cb_altitude) b1.set_air_pressure_callback_period(1000) b2.set_air_pressure_callback_period(1000) b1.set_altitude_callback_period(1000) b2.set_altitude_callback_period(1000) I would like to know, if it is somehow possible to be a bit more dynamic with the detection of the connected bricklets? For example, I have two barometers connected. I would like to output the UID of the bricklet within the cb_air_pressure and cb_altitude into something like that: def cb_air_pressure(air_pressure): # something like that: print("Air Pressure " + UID + ": .....") def cb_altitude(altitude): # something like that: print("Altitude " + UID + ": .....") Also, I am pretty sure that this can be reduced and somehow be done for each device recognized: b1 = BrickletBarometer(BARO_1_UID, ipcon) b1.register_callback(b1.CALLBACK_AIR_PRESSURE, cb_air_pressure) b1.register_callback(b1.CALLBACK_ALTITUDE, cb_altitude) b1.set_air_pressure_callback_period(1000) b1.set_altitude_callback_period(1000) b2 = BrickletBarometer(BARO_2_UID, ipcon) b2.register_callback(b2.CALLBACK_AIR_PRESSURE, cb_air_pressure) b2.register_callback(b2.CALLBACK_ALTITUDE, cb_altitude) b2.set_air_pressure_callback_period(1000) b2.set_altitude_callback_period(1000) probably the syntax is not correct - but maybe, something like that: foreach(uid in barometer_uids) { b = BrickletBarometer(uid, ipcon) b.register.... b.set...... }
  9. I am just thinking what the "best" format could be. It would be great, if the auto discover option would be able to create entities out of the different sensors directly.... So I would asume, the best option would somehow to follow the example above from my cpu_usage.... where also other information are given in the payload... In that case, it would require a own script for doing that - and including the different information into the payload... But I do will tests with the --global-topic-prefix, too - to see how the outcome in homeassistant will be :) - so, I have added the --global-topic-prefix to the command, but it seems that it was only applied to the "callback" part I couldn't see any "response" within the global topic suffic... so, checking the txt file now, if I might change the topic there.
  10. yeah, sorry - I already figured this out :D It was a bit strange, because I had somehow in mind that using the password did work in other cases without "escaping" it ... *head on table*
  11. Hi, I want to connect my tinkerforge hardware with HomeAssistant over MQTT. Therefore, I am now testing the MQTT Bindings - and they are working - so far. I received the following in my MQTT Broker: tinkerforge/response/barometer_bricklet/vNB/get_air_pressure {"air_pressure": 970609} tinkerforge/response/barometer_bricklet/vNB/get_altitude {"altitude": 49438} But - I did not yet get them into HomeAssistant, because I do need to configure the MQTT plugin still to listen to the topic "tinkerforge"... Before I do this, I just wanted to know, if it would be possible, to change the topics. Why? Because the MQTT Plugin from HomeAssistant has an AutoDiscovery option... It would automatically discover messages when a specific topic will be used. The Documentation from HomeAssistant writes: by default, the auto-discovery prefix from Homeassistant is "homeassistant" This would mean, that the tinkerforge Topic should probably changed to: homeassistant/sensor/tinkerforge/UID/config {"air_pressure": 970609} homeassistant/sensor/tinkerforge/UID/config {"altitude": 49438} Another example, for which the Auto-Discovery has worked, is the sensor of my CPU usage from my computer: homeassistant/sensor/WSCCA/WSCCA_cpulast/config {"availability_topic":"homeassistant/sensor/WSCCA/availability","icon":"mdi:chart-areaspline","unique_id":"79647378-7aaa-43d9-bfcc-675684ea6ad9","unit_of_measurement":"%","device":{"identifiers":"hass.agent-WSCCA","manufacturer":"LAB02 Research","model":"Microsoft Windows NT 10.0.19044.0","name":"WSCCA","sw_version":"2022.13.0"},"name":"WSCCA_cpulast","state_topic":"homeassistant/sensor/WSCCA/WSCCA_cpulast/state"} WSCC is the hostname of the computer WSCC_cpulast is the name of the sensor. I guess, when I want to use a similar format for the payload and topics, I have to create my own script, which does get the sensor values - and then create the specific mqtt topic / payload within the script...? That's probably not working with the default "tinkerforge_mqtt" bindings, right?
  12. ok, maybe, this fits better into the general discussion rather than on the project ideas section... :) I've noticed an issue while testing the MQTT Bindings. on my linux system... MQTT Bindings 2.0.16 I am calling the tinkerforge_mqtt with the following command: python3 /usr/local/bin/tinkerforge_mqtt --ipcon-host 123.456.78.9 --ipcon-port 4215 --broker-host 123.456.78.10 --broker-port 1883 --broker-username <user> --broker-password <password> --debug --show-payload --init-file /usr/local/bin/barometer_test.txt the password does contain some special characters - especially it is using an underscore _ followed by too exclamation marks !!, a questionmark and again an exclamartion mark: "_!!?" In this case, it seems, that the script can't handle the too exclamation marks - and does combine different parts of the other arguments. I got strange errors when executing the script, for example: tinkerforge_mqtt: error: unrecognized arguments: /usr/local/bin/tinkerforge_mqtt /usr/local/bin/tinkerforge_mqtt --h?! Here, you can see, that it has replaced the two exclamation marks from the password with the path: /usr/local/bin/tinkerforge_mqtt --h?! I am not sure, if this is an issue with the script itself - or if this might be related to the Debian - or maybe even with the Webshell from Proxmos... When I hit the arrow-up key to reuse the command, it did show the mixed-up command that was causing the issue. It happened every time when I used the command - until I've changed the password on the broker and removed these characters. After that, the script could be executed without any issues. Would it be possible to check, if this might be an issue in the script itself? Thanks! OK, I don't know why I haven't found this yesterday... !! is a logical NOT in the bash command... So this might explain the behave....
  13. I think, somehow the script can't handle " !! " which is part of my broker-password. This will always be replaced by one of the previous commands I've entered - for example, it will be replaced with "nano /usr/local/bin/tinkerforge_mqtt.... that was it. After changing the password on my broker - it did work... So, the tinkerforge_mqtt can't handle an --broker-password argument with !! in it
  14. some additions to the above... When I don't get the "Connection refused" - I am getting other error messages from the command: It seems, that the script does throw the arguments somehow together... This was the command I've typed: > python3 /usr/local/bin/tinkerforge_mqtt --ipcon-host 192.168.52.55 --ipcon-port 4215 --broker-host 192.168.52.248 --broker-port 1883 --broker-username admin --broker-password <password> --broker-tls-insecure --debug --show-payload --init-file barometer_test.txt This is the error I am getting: I don't know, where this is comming from... but when I press the arrow-up key to get the command, it has changed and (as mentioned above) mixes arguments together. Could this be a case, because my password does contain special characters like _ ! and ? tinkerforge_mqtt: error: unrecognized arguments: /usr/local/bin/tinkerforge_mqtt /usr/local/bin/tinkerforge_mqtt --h?!
×
×
  • Neu erstellen...