Bartek Śliwa: Bartek Śliwa, and this is the Euvic Talks podcast, where we connect the worlds of technology and business.

And today we’re going to demystify so-called IoT, which is the Internet of Things.

My guest is Robert Węgrzyn. Hi Robert.

Robert Węgrzyn: Hi.

Bartek Śliwa: To start, let me ask you, what do you actually have to do with business?

Robert Węgrzyn: It’s hard to say, because I’ve had my own company for many years, I’ve worked for various companies for many years, but generally the most important thing is that I try to understand what people need and I try to help them do it.

And that is generally doing business in my version.

And since I’m able to make a little bit of money on the side, it seems I come out on the plus side, so I guess that business is somehow being done.

Bartek Śliwa: Whenever I sense someone saying “a little bit,” it’s usually a pretty satisfying sum.

Robert Węgrzyn: Well, enough to make a living.

Bartek Śliwa: Sure, exactly.

You put it nicely that you try to respond to customer needs.

You said you try to help people.

And IoT is such a broad topic, and I assume you operate in many sectors as well.

What sectors are those?

Robert Węgrzyn: All sorts, ranging from industry through Health Care, Smart City, ending with RES (Renewable Energy Sources), which has been very well-known and very popular lately.

Ever since the COVID stock market boom, though not ours.

Bartek Śliwa: Well then, let’s latch onto Smart City, for instance.

Can you give some examples of your projects?

Robert Węgrzyn: Yes, we have quite a few of those, and they are super cool devices, because supposedly when you go to a bus stop and want to wait for a bus, basically you don’t see any IoT or devices there.

And yet you can check the timetable, and it shows possibilities not only at that stop, but you can click through to the stops along your route, and that functionality is provided by an Information Kiosk, which also knows what the temperature and humidity are,

so it can inform the bus shelter (Wiata), which also, completely by coincidence of course, is a device that controls heaters on the benches on one hand.

In developmental versions, there are also heaters under the tiles or paving stones.

To top it off, it controls lights, so when a bus pulls up, those lights turn on if it’s nighttime.

And by the way, it tries to utilize solar panels on the roof for all of this.

So basically you don’t see anything, but that bus shelter is under control.

Firstly, by the device on site that understands the shelter, and secondly by the entire platform that tries to pull data from the shelter, analyze it, and adjust the shelters somehow, for example so that

it doesn’t consume a lot of energy for heating, but rather optimizes it.

And as we know, bus shelters are mostly controlled by municipal offices, and municipal offices like to save on energy.

Bartek Śliwa: And we’re that modern?

Because that sounds like a vision of a bus stop straight out of Cyberpunk.

Robert Węgrzyn: Well, if Cyberpunk is in Mikołów, then yes.

Who knows what the inspiration was.

There is a whole transfer hub there that has, I believe, six such large shelters and devices, plus some information kiosks.

But there’s also an interesting detail there.

Nearby stands a Piano.

That’s another IoT device.

And that piano is actually a huge, concrete thing.

Bartek Śliwa: We’re talking about a piano for playing, a musical instrument.

Robert Węgrzyn: Yes, yes, just a freestanding piano.

Of course, very heavy and made of concrete, so that anyone who thinks of taking it on their back won’t be able to do it.

But in fact, what I enable is, for example, for it to play in the winter.

Because when it’s freezing and humidity is high,

there’s a high probability that the keys will freeze.

And then if a well-life-tuned artist walked up and tried to play something, their day would be ruined.

And I understand there’s humidity, I understand there’s sub-zero temperature, so before they sit down, I warm those keys up.

Bartek Śliwa: By “I understand,” you mean your device, right?

Robert Węgrzyn: Yes. Underneath is a heating wire controlled by

a device similar to the one in the bus shelter, which also understands all environmental parameters.

It knows, for example, that it’s not 2:00 AM, so as not to disturb people who are sleeping.

Bartek Śliwa: And what about 2:00 AM…?

Robert Węgrzyn: It’s turned off.

Yes, and that is controlled from a central administration level, meaning on the platform a person manages a whole group of such devices.

They also have real-time insight into

what the device parameters are and what is set in it.

And most importantly for the public recipient, how long during the day such a piano is used.

This directly translates into how long people play it, and that translates into how well the administration can encourage people not to just walk the streets, but also to gather in places where the administration wants to attract them, like squares,

boulevards, or near important locations,

because a second such piano stands in front of the Academy in Katowice.

Bartek Śliwa: Music Academy.

Robert Węgrzyn: I don’t think so.

Bartek Śliwa: I don’t think so.

Robert Węgrzyn: In front of the university.

Bartek Śliwa: Okay, okay.

Alright.

I’d like to return to that kiosk, the info kiosk.

I understand it’s a device of the type we can also find in shopping malls, right?

Where we can check the map and, for example, navigate to… so-called Wayfinding, meaning for example…

Robert Węgrzyn: Wayfinding.

Bartek Śliwa: Yes.

Robert Węgrzyn: Meaning simply finding the way to a particular store

by selecting the items we are interested in.

Bartek Śliwa: OK.

Robert Węgrzyn: Exactly.

But such a kiosk can also perform completely different functions, for example standing at the entrance of a car dealership and collecting keys from people who booked a service appointment remotely.

And then dispensing them back.

Such a kiosk can accept payments, of course, by card or BLIK,

it can print invoices, receipts, confirmations, and scan an ID card.

Now, such a kiosk has many applications, and they are already so well known that basically you could say it’s enough for a client to dream something up, to need something,

and you can prepare such a kiosk in a very short time and deliver it to the client.

Bartek Śliwa: And I understand that this kiosk is then integrated with, for example, the machine that dispenses those keys, right?

Robert Węgrzyn: Yes, or it even has a built-in key dispenser module inside it.

This is done in several ways, for example, I don’t know, a micro-parcel locker.

There are several doors, it simply opens, the client leaves them.

But a drop box works just as well.

The client drops the keys in, and those keys are later retrieved only by someone who

performs the repair, and conversely, those keys hang on funny hooks that are released when the client comes to pick up the car and gets them in hand.

Bartek Śliwa: Am I right in concluding that you don’t just program that embedded part, but you also physically manufacture these devices?

Robert Węgrzyn: Yes, though we do it in such a way that we build prototypes and production-ready prototypes on our side.

And it’s usually done with the client such that there is a functionality, we prepare

a piece of hardware for it, processors and components, and executive circuits depending on what we need to achieve.

And we plug this device later into a platform that we already have ready, which has gone through a trial by fire in many implementations.

Once assembled, we perform initial tests with the client.

After those first tests, it turns out we need to route paths a bit differently or add another circuit because of something.

We build a second prototype, and that second prototype is pre-production.

And then we build it together with a manufacturing company.

We have a few such partner companies.

And they do large-format production.

Of course, at the pre-production prototype stage, we have a supervisor from the company that will later manufacture the production batches, to make sure we don’t make any mistakes and that someone doesn’t tell us later, “guys, don’t do it this way,

because we can’t manufacture it.”

Therefore, after passing the supervisor and pre-production tests, we send it to the company, they manufacture, test, check, deliver, and later, if the client doesn’t have the capability, we are also able to maintain and support the devices we produce through our

help desk line.

Bartek Śliwa: Sounds serious.

Robert Węgrzyn: Yep.

Bartek Śliwa: Alright, let’s leave municipalities and city halls behind.

You mentioned industry, and that’s a very timely sector right now.

Robert Węgrzyn: Yes. And what about industry?

Well, we walked a certain path toward industrial devices

through several devices we’ve built.

And generally, we know how to design a device

or help an existing device so that the data produced within that device

transferred via some production protocol can land on our platform’s side, allowing us to analyze that data and try to influence the device back so it functions a bit better – so generally,

my direction is cost and time optimization of device operation.

To understand how this happens.

We cooperate with two quite large companies, and on the other hand we have our big brother, Google, which provides us with artificial intelligence algorithms to analyze the data

that we transmit to them.

There is a special gateway for this.

This gateway plugs into the industrial bus.

It has basically most, if not all, industrial protocol implementations.

And its sole task is acting as a relay, in fact; its sole task is transmitting all that flood of information running along the industrial bus,

after which we are able to map these parameters into ones that give us object-orientation on the analyzer’s side.

There we can run algorithms that show us, in short, correlations between the variables we get and correlations between the objects we have mapped.

Based on this, we try

to find dependencies that aren’t visible to the naked eye when programming industrial controllers.

Bartek Śliwa: So you don’t do this yourselves as humans, you also hook up an algorithm.

Robert Węgrzyn: Yes, definitely, but the output of these algorithms’ work is recommendations for changing settings or changing the device’s operational sequence.

This works a bit like

a controller, because since I have automation roots, or electronic/automation background, I generally always return to that.

A controller works in such a way that there is a meter, and that meter is basically the device capable of dumping and mapping all parameters, followed by an analyzer—something trying to optimize,

and based on that, we change settings in the device itself.

Bartek Śliwa: I understand these are all virtual modules.

Robert Węgrzyn: Yes, they are exact digital twins of the devices in the machine itself, and based on this optimization, we try to adjust the controller settings.

and that’s one direction—a direction showing how to optimize the machine’s operation itself,

while the second direction is that we are able to predict, forecast,

forecast what might happen in the machine shortly, because the parameter stream,

correlated with history, can show us that, for example, at a given feeder speed or something,

it may turn out, or has turned out three times previously, that in half an hour the machine slows down or stops because something is malfunctioning.

Thanks to which we are able to operationally decide to, for example, reduce the feeder speed—slightly lowering machine throughput—while extending its operation until we can service it.

Bartek Śliwa: OK.

Right?

Robert Węgrzyn: Furthermore, this whole setup is tied to additional things we try to implement, like analyzing what the operator says,

because their knowledge,

their adjustments on that machine, is the most valuable thing, since a person working 20 years on equipment understands it better than their own body.

Consequently, that’s easily lost, because when a person sees threats, and after 20 years of work they can feel that machine,

they basically say something is wrong or I understand something is about to shut down.

We try to catch

literally what they say and analyze it this way, correlating it with parameters flowing continuously in the bus, correlating and forecasting what might happen next.

Bartek Śliwa: So sort of a speech sensor?

Robert Węgrzyn: Okay, okay.

Bartek Śliwa: To make this more tangible, can you give an example of such a device?

Robert Węgrzyn: Yes, we made one… Aside from actual machine applications,

I have a kit for learning and training young programmers and automation engineers.

It’s a color sorter.

A color sorter might sound like a trivial name, but metal plates covered with colored papers are fed via a 25 cm micro-length belt feeder.

These plates simply move out, reach a point where laser sensors

signal that the detail has reached its destination, then a motor descends from above via a screw,

a magnet descends via a screw, picks up the metal plate, moves a bit further, and a second motor controls a horizontal feeder, moving it over a color sensor,

which is a very simple equivalent of a camera sensor matrix,

because it’s simply an 8×8 sensor matrix.

And we read the color resulting from the light reflection from underneath.

Based on this, the machine roughly understands the color, but

since there are four different bins of different colors standing further down, and at the beginning of its work the machine doesn’t know how to interpret that color, it moves to the last bin and drops it into the last bin.

But at this point, the machine can be pointed out that this color is, for example, the red bin and it should take it to the red bin.

And after such an indication, the machine goes to the red bin.

After 10-15 such measured colors and plates passing by, the machine “learns,” interprets those colors, and drops them into the correct bins.

This way, the machine can be taught—not by setting specific colors on it

like “if it’s this, go to that bin”—but the machine learns based on various color shades, learning to correctly recognize even similar colors and deliver them to a specific spot.

This gives us a touch of the industrial world, because people who program—and the task is to program the whole system, the whole kit,

programming stepper motors—must understand how a stepper motor needs to be driven, which isn’t trivial, because a stepper motor cannot start instantly; it must gently accelerate and gently decelerate.

In addition, they program the central unit connecting to the entire platform,

meaning they must understand how to securely, transactionally transmit information from the machine to the platform, and then they program an analyzer on the platform side that tells the machine what color it actually is.

So an entire quasi-production environment can be set up on a table

as a laboratory exercise to train people in all the important elements.

And then such people can be deployed to a real implementation further down the line.

Because they understand the devices, the industrial bus, the subscription server, and the algorithm capable of learning and adjusting the controller itself the other way around.

Bartek Śliwa: I tell you, a few years ago I got hooked on smart homes.

As you were talking about that color sorter, I already imagined a sorter that opens the dishwasher, takes out cups to the right shelf, plates to the right shelf, so when you build that, let me know, I’ll definitely be your first customer.

Speaking of which, moving forward, smart homes probably tie into RES that you mentioned, since there are heat pumps and photovoltaics.

What about that domain?

Robert Węgrzyn: I’ll tell you.

We managed to establish cooperation with a very cool group, a capital group that owns many plants dealing with RES

in Poland, the Czech Republic, and several neighboring countries, and we managed to enter a project where we work with them on a heat pump.

Now, we operate on two layers.

The first layer is the internal layer—meaning they let us inside the pump, and there is our card, built specifically for them, an input-output card designed to understand all parameters

operating within the pump, communicating via ModBus protocol with the PID controller installed inside.

So somewhat industrially, because of protocols, controllers, and so on, but that’s necessary for such a device to operate sensibly.

Meanwhile, behind the controller, we have… the controller connects to our platform,

communicating via MQTT protocol with the platform, and at the platform level there is a subscription server—that’s a heavy word, I’ve never managed to pronounce it normally, but it’s a server that actually accepts information from what the controller wants to tell it, and in reverse, queues those tasks and asks the platform for execution.

These tasks vary, for example,

“warning, I measured a temperature that is likely threshold-level.”

That can be one of the pieces of information sent by such a controller.

And then the platform must react to that somehow.

Of course, the controller itself…

Bartek Śliwa: What do you mean by the platform, because that keeps coming up…?

Robert Węgrzyn: I’ll explain.

Let me finish the controller part first.

Of course, the controller has preset parameters.

It’s a PID controller, so those parameters are set, and its job is simply to operate.

So if we unplug it

from the network, it will function according to what someone set and what settings they consider correct and most sensible for that household.

However, connecting it to the platform

offers much greater possibilities, because the platform basically consists of two important elements.

The first one accepts information from the controller and sends commands back to it.

That’s the subscription server—success—which, once this information is fed into it, has the task of pushing it sequentially, as it arrives, to the second part of the platform, meaning the part that can receive those commands, understand them, and based on

the command and the controller’s parameters (since it understands the controller’s parameters in real time), can devise better control settings, figure out better controller adjustments, and send those adjustments back to the controller itself.

So speaking plainly,

our ambition and task is to prepare this so that after configuring the whole pump on-site, once it’s started up and the installer sets it up according to their best knowledge, all data continuously streams to the platform.

The platform accepts it, queues it, stores it, and sends it for analysis.

That analysis consists of various algorithms—we use deep learning and genetic algorithms, depending on which fits the process characteristics better.

But effectively, we get this data and wonder on the platform, using these algorithms, how to adjust the controller settings to make it more optimal and better fulfill energy consumption conditions.

And the moment the client allows the platform

to say, “look, I’m smarter and generally I think this would be better,” the client sees these suggestions on the pump’s controller itself and can—well, not on the controller itself, that’s what the app is for—see them and accept them.

And at that moment, a learning process begins that probably never ends, because optimization can be carried on infinitely,

but it should be very clearly visible and well-felt by the client.

This is an idea for a completely different quality from a pump manufacturer, so that people using the pump feel it’s not a device that is set once and just runs without knowing what to do with it, but rather an ongoing learning process that improves that specific pump.

And that is their advantage, because right now there are no such products on the market.

Bartek Śliwa: Does this pump also, colloquially speaking, talk to other devices?

Robert Węgrzyn: Yes, it talks to other devices.

The group itself produces a whole range of RES-related devices, meaning photovoltaic panels and solar collectors.

The ultimate element is a home assistant

that understands energy expenditure and thus understands what can be done at any given moment to make everything function as best as possible.

And since we are in the era of a galloping path toward artificial intelligence and assistants that speak, hear, answer, and understand what is said to them,

we also already have a module that functions in such a way that, firstly, it hears what we say, secondly,

it recognizes not only recorded commands but regular colloquial speech, responds with understanding, and on the other hand, those understandings are

backed underneath by all the parameters it has at its disposal.

Meaning it can cooperate in real time with all devices, understands those devices, understands temperature, humidity, understands everything fed into the system through every possible sensor.

This gives us capabilities where, colloquially speaking, if I said I was cold,

and the assistant was listening at that moment, it would reply: “well, let’s try raising the temperature on the gas furnace a bit, because the external humidity is X, and I think if we did that for just 15 minutes,

you would already feel the temperature change, and probably in 15 minutes it will be better to switch from the gas furnace to the heat pump.”

And so on, and so forth.

You can fill in the rest yourself.

Bartek Śliwa: I’m wondering about one thing.

As I listened to your devices and their real-life applications, I already had several ideas in my head of what could be done.

How can someone reach out to you, or what do you need to have in order to contact you so you can help maximize business profits or improve a workplace?

I mean, suppose I’m an office owner.

I’m listening to Robert Węgrzyn talking about a piano and thinking, it would be cool to have a machine like that in my office.

What should I bring when I come to you?

Robert Węgrzyn: Just come.

Just come.

Just come, because IoT is a philosophy.

These aren’t just devices.

You can’t just say someone manufactured something.

IoT is like intelligence that is everywhere, because in a microphone, a mug, a watch, anywhere there can be devices that give us a little bit of capability to know.

For example—slightly exaggerating—how much coffee I have left or what temperature it’s at.

I mean to say, these devices… equally well, such devices exist—for example, we are also working on the possibility of controlling pumps that assist heart function during open-heart surgery.

These devices can be everywhere.

The most important thing is what we said at the beginning: devices give us knowledge.

They understand parameters they operate in.

We can acquire this knowledge and analyze it.

If the device can perform something locally, we can teach it to perform a bit better.

And the strength of these devices is that there are many of them, so we can multiply that intelligence through how many there are.

Because in fact, when we understand parameters and can adjust them—and let’s assume there are many such devices in a given area or environment—we can teach them together so that their actions are correlated.

And the future of IoT lies precisely in the fact that if someone dreams up and thinks about what they need or where—in one place or multiple places—if we can match it with, to put it colloquially, an endpoint that understands those parameters and another that can execute them, we are capable of

implementing most such conveniences or processes, and most importantly, optimizing them later.

So just like in life: someone does something, but it turns out that if we fully understand it, they might be able to do it better.

Right?

So this knowledge,

multiplied by the fact that there are very many such devices and they form a kind of matrix, a network—I don’t know what to call it—gives us immense possibilities for improving life.

That’s about it.

Bartek Śliwa: Nothing to add, nothing to subtract.

Robert, lastly I have a question.

What inspired you lately?

It could be a book, a movie, an activity you started, a journey.

Robert Węgrzyn: There is one novel, you could say.

A novel that inspired me a bit,

because for some time in my life I really liked books where, you know, “they killed him and he escaped.”

Where the main protagonist jumps out of a helicopter at a height of three kilometers with just a piece of plywood and glides somewhere

to a river, lands there, and it succeeds and everything works.

But later I decided to take an intellectual break and just read a book about life.

And nothing else, because life probably inspires the most,

since it’s the result of many millions of years of evolution.

I read War and Peace.

It was hard, because I read it exclusively while traveling, meaning on a train, because otherwise there isn’t much time.

Some people make sure I don’t have that time.

Generally, what I took away from it is, let’s say, strategy.

Something that helps me tremendously in daily life, meaning in project management.

And specifically strategy—it’s not contemporary, but Napoleon’s opponent,

meaning the colonel who commanded the enemy armies, even the French—I deliberately won’t pronounce the name because it’s unpopular right now.

His conduct regarding how he managed to back Napoleon’s army into a corner solely through calmness and analysis of what would be strategically better, and how thanks to that he didn’t lose

many people, and how thanks to that he defeated Napoleon essentially using his own strength—and since I always repeat, and somewhere early in life I practiced a martial art called judo,

where basically everything is done solely using the opponent’s strength,

generally that book showed me that strategy based on understanding

and utilizing the opponent’s strength to deal with them is actually applicable in every possible situation.

I don’t know if that’s inspiring to you, though.

Bartek Śliwa: It was very interesting to listen to, surely profound.

I didn’t expect such an answer.

Awesome.

Robert, thank you very much for today.

We also thank our listeners and viewers, and I invite you to the next episode of the Euvic Talks podcast.

Robert Węgrzyn: Thanks.