syntax question
-
Hello, I am working with a Wipy3 and a pysense2 board and am trying to send some sensor data to a broker running on my local machine.
This is the correct format that I need:
``` mqtt_publish(client, "home-assistant/altitude", value)
The data is returned this way:
str(alt.altitude()))
I may be mistaken but I think the data should be a string, if I am right then would i enter it into the publish line similar to this:
"home-assistant/alt.altitude"
or some other way? I can't seem to find an example that uses something other than light on or off. thank you in advance
-
@Mr-Admin said in syntax question:
mqtt_publish(client, "home-assistant/altitude", str(alt.altitude).encode('utf-8'))
thank you, this looks like what I need
-
I used to have a HomeAssistant setup that let me map the location of my Lopy4/Pytrack device, but I moved home and started a new HomeAssistant build that doesn't support this yet.
My code for publishing the position data looks like so:
def lora_handle(self, msg): try: fields = msg.split(b',') # see if it looks like a nav beacon and has at least a 2D fix if len(fields) == 5 and int(fields[1])>=2: lat_str = str(fields[2],"utf-8") if lat_str[-1:] == 'N': lat = lat_str[:-1] else: lat = '-'+lat_str[:-1] lon_str = str(fields[3],"utf-8") if lon_str[-1:] == 'E': lon = lon_str[:-1] else: lon = '-'+lon_str[:-1] payload = '{' payload += '"latitude":'+lat+',' payload += '"longitude":'+lon payload += '}' src = str(fields[0],"utf-8") print('LoRa Rx Nav: '+src+' '+payload) topic = 'homeassistant/location/'+src self.client_try_publish(topic,payload,False,0) except Exception as e: sys.print_exception(e)
The method self.client_try_publish() has an interface like:
def client_try_publish(self, topic, msg, retained, qos)
and it mostly just checks that the wifi is up, that the mqtt client is connected, locks a mutex to ensure that only one thing is publishing at a time, and handles all exceptions that might occur.
Hopefully this info might be of some use.
Before I moved, I was also working towards changing my arbitrary mqtt topics that report info from my Tempodisc THD sensors received over BLE, into something more hass compatible, such that they might be autodetected, but that has been given a right good ignoring since the pandemic began. I did get as far as making my Lopy4's publish their availability as a binary sensor. This stuff is announced using this kind of thing:
self.hass_availability_root = b'homeassistant/binary_sensor/'+self.client_id+b'/'+self.service self.hass_availability_config_topic = self.hass_availability_root + b'/config' self.hass_availability_state_topic = self.hass_availability_root + b'/state' self.hass_availability_config_payload = '{' self.hass_availability_config_payload += '"name":"'+str(self.client_id,"utf-8") self.hass_availability_config_payload += '","device_class":"connectivity",' self.hass_availability_config_payload += '"state_topic":"' self.hass_availability_config_payload += str(self.hass_availability_state_topic,"utf-8") self.hass_availability_config_payload += '","payload_on":"Online",' self.hass_availability_config_payload += '"payload_off":"Offline",' self.hass_availability_config_payload += '"availability_topic":"' self.hass_availability_config_payload += str(self.hass_availability_state_topic,"utf-8") self.hass_availability_config_payload += '","payload_available":"Online",' self.hass_availability_config_payload += '"payload_not_available":"Unavailable"' self.hass_availability_config_payload += '}'
If that kind of thing is of interest I could possibly dig up more of the associated code.
I am hoping to finish off this stuff one day, if the IDE and PyMakr plugin keeps working, but I haven't been particularly motivated to do it recently. The code that I do have seems to be working fine, and I have hass config yaml that reads the THD topics and displays the info nicely on the dashboard without bothering with the switch to auto-detection compatible topic content.Good luck.
-
@Daniel-Bell
As I understand it the home-assistant doc is talking about sending messages FROM home-assistant to a device (eg a smart plug or a smart light) and it has 2 ways of formatting the data : 'payload' or 'payload-template', of which the first requires a plain string.... but this is not relevant to your case, as you want home-assistant to RECEIVE the data from your WiPY.For your sending of the data (which home-assistant will be listening to - the 'Listen to a topic' part of the dialog), you could try :
mqtt_publish(client, "home-assistant/altitude", str(alt.altitude).encode('utf-8'))
which will let it receive it as a string of digits....
-
@Mr-Admin thank you and that helps.
I did find this info about using json:
"payload must be a string. If you want to send JSON then you need to format/escape it properly. Like:"topic: home-assistant/light/1/state payload: "{\"Status\":\"off\", \"Data\":\"something\"}"
Would my data look like this then:
topic: home-assistant/altitude/1/data payload: "{\Data\":\"altitude\"}"
But I am hoping to keep things as simple as possible. In the published example, I followed the path of setting up the broker to receive data as SERVICE MQTT.DUMP with # or + used as a wild card Like this:
In my main.py file would this get the data in the correct format assuming it needs to be a string? I must be missing something simple like taking the result from the pysense of
str(alt.altitude()))
and setting it equal to "alt.altitude" perhaps like this:
alt.attitude=str(alt.altitude()))
then adding the publish code like this?
mqtt_publish(client, "home-assistant/altitude"
Am I close?
-
@Daniel-Bell
Hi,
MQTT needs the topic name as a strng ("home-assistant/altitude" in your example) and the message contents as a byte array.So if you have a string 'mystr' you could pass it as
mystr.encode("utf-8")
.Note that home assistant, will probably want the value to be something like json that it knows how to parse, but I don't have any experience with that...
I use JSON with my MQTT setup, so I'd do:
data={ "alt":alt.altitude() } mqtt_publish(client, "home-assistant/altitude", ujson.dumps(data).encode("utf-8"))
YMMV...
Brian