So I'd like to introduce Fabrizio, who will talk about actors in the home. I have no idea what it is, but we're going to find out, right? Not sure, but... Well, mainly this talk is... A big round of applause, please, Fabrizio. Thank you.

Okay. Well, the talk is to explain what is changing in these days, in this year, on the home automation.

In the past, we had home automation mainly based on wired cable in the wall and no phone. I can speak a little bit louder, but no phone.

As I said, in the past, we had many proprietary protocol, but was mainly designed as a PLC, no more controller than real Internet of Things. Today, we have a lot of solution, very cheap, that you can control what you want, sensor, actuator, and so on.

Now, for example, in Intel, it is only to have a dual core with wireless inside, and it's probably 4 cm. The same for SparkIO, that has a really small chip. And Bundabar probably is quite famous for many of the Internet of Things guys.

The problem is we have the device, but we don't have the technology. Or rather, nothing changed in technology of the 80s or 90s. We have mainly one solution for home automation. It's a central coordinator. You have a central station that gets all the information and takes the action. Single point of failure, but it's not the Internet of Things that we are thinking.

The second solution that's like SparkIO, they try to collect the sensor, the IoT, in the cloud. But there are also other vendors, but mainly our hardware, single vendor, a little bit close. It's not really Internet of Things, from my point of view.

Then I start to think how to create a home automation and keep decentralized, high availability. Because probably you don't like to restart something if your light doesn't work, or your heater doesn't work. The problem is that we have a big step ahead with the new devices, because all the devices have wireless.

But on the other side, you don't have much CPU capacity, if you want to keep the price low. Thinking and thinking, at a certain point, come up in my mind the university and the actor model. Okay, that's in the last year, probably it's quite high on the IT.

How many people know what is the actor model? Well, that's 20%. Well, first of all, it's not a person that acts. No, this is not related to acting. But it's a mathematical computer science where we try to define a new approach.

Many principles are no shared state. That is perfect if you want to build a distributed system. Second has to be light. This is perfect for IoT, where you don't have capacity.

And also has to be asynchronous, because you have sensors around, you have events. You don't have something to code, you can't stay to wait forever. No, this is a complete asynchronous environment. And the other two that are quite interesting are, okay, any process, really, really light process,

as a mailbox, where they can receive the event, where they can receive the message. Simple message, if you want to do something, you send a message and you have a state, without any shared state around. From this model, it's quite simple to figure out a wonderful home automation,

where you have a lot of small actors, this is the terminology, that has a single function. For example, you can have a temperature sensor that's sent to a thermostat, that's a thermostat based on information received. Start another actor or send a message to the valve to close and open.

Same for alarm, same for the light. No, you turn on, turn off the light and you can also create scheduler. No, that is a great abstraction. You don't think about hardware, you think about functionality or better. That is correct, probably someone can kill me if I say that that is a functionality.

But what I want to say, that you have a huge, all these balls around that go left and right. But the main problem is how to find, because many implementation of the actor model in the language that we have is inside of the VM.

That is simple to find the mailbox if you are in the same VM. I don't want that. I don't want to find the actor that is around somewhere. Let's introduce the problem that is not solved and try to solve on the look-up mailbox. No, you have a lot of actors around because it could be that you have the actors inside of your device

or you have a Raspberry Pi that exposes actors. You can have a lot of situations. The basic idea of my implementation is to divide, first of all, define a domain. That mainly is a DNS domain.

Inside of the DNS domain, you have a small cell. Inside of the cell, you have an actor. Each cell exports a JSON RPC interface. That is really simple. And all the actors are controlled by the arbiter that is a supervisor of the actor.

But the problem of the mailbox is not solved at the end. Then I try to find or create a registration service. I build a registration service on top of the console. Console is really small. It's possible to run in Raspberry Pi, for example, or also in Edison. And these are no SQL, very light and no SQL distributed system

with the draft work coordination, the text of the failure and so on. That means each cell can run or not depends if there are enough instances of the registrator inside of the domain. The registrator gives you the mailbox that you are looking for.

It works. It works quite simple. First of all, I need to figure out the IP of the registrator or the console cluster. Then I use 0.conf. I have also DHCP that you can return some information from DHCP if you have an infrastructure. In my home, I don't have a DNS infrastructure and I don't want to put on it.

Then the lookup of the IP of the service locator comes from the 0.conf. Then the cell or rather the actor depends on the operation. First of all, I have to find the console cluster. After that, it can retrieve the mailbox or the configuration.

Everything is in the console. I don't have to make configuration inside of the cell because the configuration of the cell is in the side of the registrator. When you have the configuration of the address of the other actor, you can send your message.

This can be in any cell. You don't care. This is a transparent layer to make the lookup of the mailbox. A small demo, I hope.

Okay. I start the server and the server in debug mode. The domain is my house. The cell name that I'm starting because this is a single cell is a raspb1.

The bootstrap type that I want, the way that I want to catch the console IP is 0.conf and the local IP address is localhost. Okay. First of all, the process tries to figure out if there's already some console somewhere.

Okay. If there is some console DB, then I made the lookup and I didn't find any registration. Then I start a new console, a new server locator.

I hope it could be that in the future I will change with other solution. After that, I verify that I announced correctly that this console is up and running and I get the configuration of the raspberry of the cell. And then I get the JSON. Everything is JSON in my implementation.

When I found the configuration that I can show you, cell configuration raspb1. Okay. You can, yeah, unfortunately it's a little bit small.

You can see, okay, I want to stay on this part and I have this actor in my cell. If I go back to the startup, I've seen this resolution. Each element is getting the configuration of the actor and I start the actor.

Also the configuration of the actor is inside of console. And then I prepare and I starting the actor system, the worker or the ambiter. Now what I can do, I have defined for this small demo four actors.

There are valves, one temperature and one thermostat. I can use a simple common line, for example, this one. I want to get the status of the valve. Then I define, I query the system with only the name.

That could be the UID, depends. You can put the name that you want but have to be unique because you are in SQL. There's no SQL. I run the first thing executed by the common line is to find the mailbox and find the second.

No, I find the address of the mailbox where is also the actor and after that I get the position of the valves. I can also set the position of the valve to 60, my fault.

This is a little bit better. Okay, then it's a simple way to have the control of the device that you can set and get. That is mainly the protocol. The protocol is dividing set and get and in channel because in one device could be that you have multiple operations

and up to you decide if you want to use a different RPC code with a different name with a different actors or stay in the same actor with a different sub function. But I don't want to expose multiple function on the actor.

Actor has simple get and set. This covers most of the case. Another case is the thermostat and the thermostat is a special actors because it's a scheduler that is executed every minute like this one. This is a more example.

I run thermostat one. I get the configuration thermostat one. In the thermostat one, let me check the configuration. We have where is the sensor and where is the valves. What happened here? If I start, it doesn't work.

Yeah, this is zero.conf. Yeah, this is probably every 10 seconds. I have to reduce a little bit. First of all, they get the configuration and it's broken.

Then this demo I probably I don't have to run again. Yeah, that's I prepared before. What I want to show you that mainly you get and send message and then you keep the balance between the temperature that you have in the room and the status of the valves.

Let me check again. I will see later. Okay.

As I said, protocol is based on RPC base and we have mainly three elements. Channel command that is only set and get and the payload, that's the string of the element that you want to send. I have two main configuration, the set configuration and the actor configuration.

At the moment, the entire Python that's with the console, that you have to install the console and install some module Python. Not other binary library, it's pure Python and you can write an actor with a really few lines.

Because everything is handled by Pulsar, that is an implementation of the actor, one of the implementation of the actor in Python. As you can see, there is a small init, but mainly you receive a message because you are a RPC. Then you have to define if you have multiple channels, obviously you can do in many other ways, but which channel and after that you can apply the command.

If you have a Raspberry Pi with a GPIO, that is enough that you know the part and that you can put the part or the configuration of your hardware is directly connected in the JSON configuration.

Okay, what I built with this system at the moment, I have mainly three elements, this is coming soon. One for control or heating and security and other small stuff based on homematic.

Then I have a bridge on the homematic protocol based on the Raspberry Pi. I have an addison board with some sensor that I use to catch the temperature or the wind or also some movement and also the light.

And I have API main board that is mainly in a gateway. This wireless, all the elements are connected by wireless and the wireless is dedicated to the control of the house.

I have also, I still have some small X10 around. In the future I will have also Z-Wave to control some power meter because there are more power meter. What I want to show mainly that you can decide to use the hardware that you want. You don't have to care, you plug in.

You can build your actor and immediately you can control and connect all the system. Like this morning I've seen a really wonderful thing based on zero MQ that I'm thinking I won't move there. At the moment it's quite really naive and there are a lot of things that I want to improve.

And I'm starting to work in special way on the reincarnation and migration of actors. At the moment I define the actor based on the configuration, this is static. I want the actor to be able to go around on different hardware if the hardware has the capability.

And also I like to have the failover, that's also for I want to turn on my light all the time. The last one that is quite simple, I want also to avoid any preload of the configuration or whether the actor software. I want that when you have to start, when the cell decides which actor have to start, have to download also the code.

That you have an automatic deploy your last change and also reduce the time to prepare the hardware. I like to also optimize a lot of the protocol because the JSON RPC is not the best way.

Probably it's not the best solution but at the moment it's really really simple. I like also to try a way to collect the event and create alarm.

Question? If there are questions, otherwise. Can you repeat the question?

I repeat the question. Why at the moment the software is based on Python and one of the plans is to move from Python because honestly it's really fast to prototyping.

Really really fast. I want to show you, as I said, you have seen already the actor but the entire code, the entire code, also the supervisor, I don't know who control and start the actors is 20, 30 lines.

That's quite amazing. Yes, the actor in Python is a little bit of pain. That is true. And but also I have to, if you want to move on the embedded device, you have to figure out if it's supported or what is supported.

At the moment I think the goal language is quite simple to go across all the platform. But I want to think on it before to move completely on the goal language. Because other language I think is too difficult to run on small hardware.

I have a question probably too. Yes. Did you look at zero and q yet? No, but from this point, well, yes and no. Yes, in the beginning and mainly I have also to figure out how to keep the number connection and request, well this is the next step, as small as possible.

And I believe, well, zero and q, you have to open and close, you have to proper a little bit around on that. I use for other stuff, that is great. But this morning I see your presentation about that I think is really, really what I'm looking for. I have to understand how to put in the actor model.

This is the, I will check because I never seen before, I searched something, I searched some solution I didn't find for this reason I started. And also I didn't find your solution based on the protocol. The protocol is the biggest part. Because in special way for example, Homematic that has a broad number of devices that are based on battery.

And they really have a high, they put a lot of small feature to reduce the energy consumption. And I believe we have to do the same for Internet of Things.

Then reduce the number of connection, reduce the energy user, that means reduce the traffic. There is some compliance that I think for the 833 megahertz that you have to stay below 1% per hour of the transmission. And I try to figure out something, some target also for system that is based on wireless.

Yes. One more. Is there any consideration on security? I know that it's early stage yet, but if I understand correctly, now it's mostly dependent on the underlying network security?

There are two parts, there are two parts. But yes, security is complicated on the IoT. And I've seen, well, I use Homematic because probably most of the people use Homematic. The people that knows quite quite, from Germany is quite famous.

When they introduced, well, if you use the security that is encryption, you spend 200 milliseconds instead of 10. I don't remember exactly. How is it secure? If the user console has an ACL, then first of all, the actors are not able to change the configuration, no. That means other cells can't change the configuration and this is quite important.

On the message level, at the moment I don't have, I try to figure out the usual sharing key somewhere, like teaching most of the device that is appearing like ZetaWave and so on. But I like to find the way that the operations are to be really simple, fast

and probably you have to figure out a way to deploy in a massive way because IoT could be that you have 100 devices in your home. Then I have to think on it, I didn't find a solution at the moment, to dedicate a network,

avoid to change any configuration on the console and yeah, I don't know if it's public, it has to be a shared key and this is a mess.

Yes, I'd like to introduce Zero&Q. Well, I'm thinking on it. Well, replace the protocol, remove the RPC, JSON RPC.

Or also in that case, that's the transfer layer. I have to understand better the format of the package. I like to keep simple, like get and set and the concept of the channel because I've seen this is around and I have to figure out the new devices. But I believe the get set should be covered 98% of the case.

Also, for example, the scheduler, you set the profile. In that profile you have the time frame, the schedule of the time frame when you want to change the temperature, when you want to shut down the device. Or the sequence of the device that has to be shut down.

Then it's quite a gnostic and for IoT at the moment is... Thank you very much. Thank you.