How to get value from rpi into Igntion

Hi the examples from git are python v2.9 i think.

You have to go through all the code and search replace the print statements and give them brackets.

From my requirements.txt :

paho-mqtt==1.5.1
protobuf==3.13.0

From my sparkplug code:

  

import sys
sys.path.insert(0, "tahu_python3/client_libraries/python/")
#print(sys.path)

import paho.mqtt.client as mqtt
import sparkplug_b as sparkplug
import time
import random
import string

from sparkplug_b import *

As you can see i have renamed the sparkplug lib tahu_python3 after i did the search replace

Hey Kyle, were you using sparkplug B, any luck you’ve had a chance to finish this off? I got the sparkplug B client working, but there’s a bit involved to get it into a user-friendly state!

Sweet, I got the example working. Turns out I was 1) using an older library version and 2) didn’t realise the library was in the client_libraries folder. Cheers! As I said to Kyle, there’s a bit involved to convert this into a user-friendly library to use on generic projects :confused:

Nice!
I agree with that. I find node-red to be more user friendly that way, but node-red is not always applicable.

Im currently struggling a bit with the Python library regarding death messages. If you disconnect your client, are the data in Ignition marked as “Stale”?

Is anyone mange to read gpio from python script in ignition itself?

Jython cannot load the shared libraries that provide full access to the GPIO pins. The pigpiod service is your best bet, but no-one has taken the time to test/deploy in jython yet.

I am using Sparkplug B, let’s get a time to sync up today or tomorrow and I’ll work on getting it up to GH eventually. Not comfortable posting it yet, but can get you access.

1 Like

Sounds great, cheers :slight_smile:

Yes, my tags do turn Bad_Stale when the client disconnects.

I’m having some issues with it connecting if Ignition isn’t running before the MQTT client is running, or if Ignition drops out and loses connection to the MQTT client (such as stopping the Distributor module and restarting or disabling/re-enabling it). When I go to publish my new values, i’m looking at the return value and checking if the QOS is 4 (bad??) and then issuing a client.reconnect(). This reconnects the client, as evidenced by the QOS ret from the publish now = 0, but Ignition’s tags are not getting updated anymore and quality is stale :confused:

Edit: I had to issue a client.disconnect() first and then re-establish the whole connection with startMQTTClient(). client.reconnect() appears not to work…

Feel free ask me any questions about the Sparkplug specification and specifically how Ignition MQTT Engine behaves when you throw weird corner case messages at it. I’ve intentionally and unintentionally done a lot of non-standard things and then had to analyze the results while working on our product.

Ignition sends out rebirth messages to nodes that its missing info about. Are you sure you cannot just rebirth, instead of reconnecting.

When you say it sends out rebirth messages, how does the spark plug b client code handle that? Is that in an event callback function somewhere?
I’m having lots of issues atm. Ignition will be happy and receiving data from the mqtt client, and then some time later it’ll just stop getting data. Not sure why…

MQTT Engine will send an NCMD message to a tag named “Node Control/Rebirth” and it’s up to each client to how it implements the NCMD handler for that tag. You’ll need to add a on_message handler for Paho and have that call something like this:

def _mqtt_on_message(client, userdata, message):
	mqtt_logger.debug('RX topic=%s bytes=%d',message.topic,len(message.payload))
	if message.topic.startswith('spBv1.0/'):
		rx_payload = sparkplug_b_pb2.Payload()
		rx_payload.ParseFromString(message.payload)
		# TODO - Add your custom payload handler here
	else:
		logger.info('Unexpected message on topic %s',message.topic)

The sample client libraries in Tahu are a bit more minimal than most people would like right now. I know there’s some effort within the Eclipse team to improve that, but it may be a while. :frowning:
This also presumes you’ve already subscribed to an appropriate MQTT topic to receive NCMD messages back to your device.

You got that right! I might have to give up on this for a bit as I just don’t have the time to mess around with it. I’ve already got a webserver on my pi working and publishing the flows and a bunch of other stuff, so that’ll have to do for now :pensive:

Thanks for the input though. If I get time i’ll have a look and see what I need to do to fix it using the on_message handler. I reckon I saw a function defined already, not sure what’s in it though.

Big code drop you might be interested in (specifically the python_edge_device branch):

I haven’t done anything to make templates or datasets any easier, but the ability to implement an edge device in Python is vastly improved, all the integer casting works both ways… Take a look at the standalone_examples/python/example.py to see what using it looks like now.

For now the Sparkplug management is running in a separate thread, although I could make that be a callable function like the paho library does with MQTT.

If I have time to keep pushing this forward I will likely start a pull request with the official tahu maintainers, but … I changed a LOT.

3 Likes

I ended up giving up and just writing the tag values into a local csv file, then reading that in ignition and setting the tag values. Super simple and it works 100%. I don’t have free time these days, so couldn’t look any more into other libraries :slightly_frowning_face:

Is your code up on github or anywhere? I’m curious to see how quickly I could get it into Sparkplug, already understanding that side of the problem.

Sorry for the late reply, my code isn’t up on git and really it would be more trouble than it’s worth - I would just consider that I have a handful of variables that are mostly bools and floats that I need to get into Ignition.
I’m actually instead looking to use bottle to serve my stuff up using restful api calls, with inspiration from Kevin’s post

This post is interesting too: