I have seen a lot of your content on KZfaq and I learn a lot from your videos and I thank you for that. I would like you to talk a little about LoRa and other forms of wireless networks, which ones do you use the most and what do you think is the future in this field.

You remind me of Hank from breaking bad so much XD Great content!

Awesome thanks Walker and Team 🤟

What is especially great about this video is that Walker not only gives a 10,000 foot view of Sparkplug B from a technical side, but just as importantly gives the reasons for it and where it can be used to yield the most benefit. The latter is something that is missing from most technical explanations, a "when to use what" side of things. Well done 4.0!

If I understand correctly the Sparkplug namespace (SNS) is basically independent from the rest of the namespace and can typically only interact with a subset of clients. Further to this, because the Sparkplug B spec dictates that the format of the topic structure is governed by the topology of the EON Nodes, it isn't necessarily possible to structure the SNS to align with a Plant/Area/Line/Cell factory model - especially if you plan to use something like Highbyte where it can be the Sparkplug B EON Node for the whole plant. This means SNS clients can't rely on the SNS topic structure to be normalised from plant to plant - this could only occur within the payload metric naming. Does it make sense to think of the SNS as a distinctly different layer from the UNS, each with their own strengths? SNS data can be translated and/or transformed by SNS Clients and published up to the UNS where required for comsumption by more plain-speaking clients that rely on a normalised factory model.

Thanks a lot for the videos. I really wanted to understand what is IIOT but not only I got the answer to it but a lot lot more. All your topics are nicely explained and i couldn't have asked for more.

Great Video. I watched this a year ago and I am now Implementing SparkplugB for one of our projects. Quick question: Do all SparkplugB clients support store and forward as a default property?

Hi! Is there a way to configure everything in a SP namespace to publish even if the values have not changed and just publish the latest value for everything?

Question: It's excellent that Sparkplug B natively supports Store & Forward. In a plant situation this might not be as important due to the fact that the networks would be "wired" and super reliable. But in a case of let's say cellular connections (which are sucky) it would be very important. What I am curious about is the use of flat MQTT 3.1.1 over cellular. In these types of implementations that you all have done over the years, did you all have to do custom coding to implement Store & Froward? How did you all handle prevention of data loss over "unreliable" connections such as cellular, using just plain ole vanilla MQTT?

Thanks for another great video, you really are creating great eduactional content and this helps a lot for the understanding of how to digitally transform a business and select the best tools for the job. Coming back to this video a second time after learning about UNS, MQTT and all the great benefits that comes with it, I have a few questions; 1. The MQTT broker, does that typically live on premise or in the cloud? And does it serve as the UNS? 2. Also for the SparkplugB do you run this on premise (I would guess yes)? 3. Where does HighByte or other DataOps softwares live in the ecosystem? Between the legacy equipment not running MQTT natively, or does it replace SparkplugB? 4. When connecting the UNS to an ERP system, if the ERP system does not support MQTT natively, what do you put inbetween the UNS and ERP? Thanks

Excellent information!

So in the flat 3.1.1 example, if you publish a temperature, you can't (easily) publish extra context? Such as Fahrenheit or Celsius? Certainly you could add extra topics covering that, or whether it's a HIGH or LOW temperature for the day (on in the context of a machine, HIGH or LOW for process controls), but this seems tedious and less scalable.

Can one node be in more number of groups?

One thing I had difficulty understanding is when the SPb publisher is sending binary data over the wire and you mentioned that vanilla 3.1.1 broker cannot decipher but can pass on to another SPb subscriber. How do they align on the proto file that would be needed to pack/unpack the data? Do I manually maintain the proto files for both sides? Or is there some inherent maintenance in the standard?

I'm researching the possibilities wits a Siemens S7-1500 PLC, Siemens has a library that supports MQTT 3.1.1. Because the library is MQTT 3.1.1 does this mean it supports Sparkplug B or not? If not do I have to buy an EoN device that is connected to the Siemens PLC wich is compatible with Sparkplug B? And where can I find out if my EoN device is compatible with Sparkplug B? Hope you or someone can help me, it is hard to find the answers to these questions.

While using Spark plug B , the bandwidth requirement for payload transfer is higher right, how that will be suitable to lightweight MQTT protocol??

The topic structure is standardized. Aren't just two levels of hierarchy a big limitation for large implementations?