Programming Intelligent IoT Systems with a Python-based Declarative Tool? Fabio D’Urso, Carmelo Fabio Longo and Corrado Santoro Dipartimento di Matematica e Informatica - University of Catania Viale Andrea Doria, 6 - 95125 - Catania (ITALY) {durso,santoro}@dmi.unict.it, fabio.longo@unict.it Abstract. IoT applications are traditionally characterised by a set of interacting small devices equipped with microcontrollers (MCUs). Ba- sically, they are often programmed in bare-metal using the C or C++ language; however, IoT applications are becoming more sophisticated thus including forms of autonomous behaviours that, in some cases, have the objective of presenting a certain degree of intelligence or reason- ing; but since reasoners are traditionally designed using logic/declara- tive approaches, their implementation into embedded devices that use C/C++ as the main development language is no simple at all. Neverthe- less, there are a fair number of porting of high-level languages to MCU platforms that could help to overcome the cited difficulties; and among them, MicroPython is one of the most interesting: it is a fully-featured Python environment running on a wide range of MCUs, also providing a small memory footprint and good performances. On this basis, this paper presents a Python framework called PHIDIAS that allows the develop- ment of logic/declarative code seamless running into a Python program. PHIDIAS is able to give Python programs the ability of performing logic- based reasoning (in the Prolog style), also letting developers to write reactive procedures, i.e. pieces of program that can promptly respond to environment events, which represent a typical case in IoT applications. PHIDIAS also includes a library for the interfacing of I/O peripherals of a microcontroller. The paper presents the PHIDIAS framework, high- lighting features and advantages, and also provides a case-study in order to assess the effectiveness of the proposed solution. Keywords: IoT · Multi-agent systems · MicroPython · Logic/declara- tive programming 1 Introduction In the last few years, the development of the Internet-of-Things has led to the introduction, in the market, of a wide number of small devices featuring very different functionalities but able to interact to each other, and to other kind of ? Copyright c 2019 for this paper by its authors. Use permitted under Creative Com- mons License Attribution 4.0 International (CC BY 4.0) 2 Fabio D’Urso, Carmelo Fabio Longo and Corrado Santoro systems, with the objective of helping us in day-to-day activities [12]. As just some examples, many car models are “smart”: they are still tightly integrated with our mobile phones, and it is expected, in the near future, that they will be able to interact with other cars thus improving driver comfort and safety, or reducing travel times, fuel consumption, etc. In a similar way, our homes are becoming full of smart objects, starting from smart switches, smart lamps, surveillance cameras, up to vocal assistants, such as Amazon Alexa or Google Home, that allow occupants to control the whole home by means of voice com- mands. Such devices are usually equipped with microcontroller units (MCUs), and include, apart from proper sensors and/or actuators, which are relevant to the specific features of the device itself, a connectivity module i.e. a Wi-Fi or Blue- tooth chip for the interaction with other devices. From the software development point of view, these devices are in general programmed using the C or C++ lan- guage, with a development environment that often includes some libraries pro- viding an abstraction layer for MCU peripherals; the developed firmware runs on bare-metal and only in very few cases an operating system (which is usually a small real-time executive) is included. The current generation of such IoT devices are limited in functionalities, that is, smart sockets or smart switches have usually the capability of receiving or transmitting the on/off command, and sometimes include also measuring sensor acquiring data such as current or power, which may be useful to monitor energy consumption. But it is expected that, in the very near future, such devices will have the ability to exhibit a certain form of “intelligence” thus performing, in autonomy, tasks that could derive from a reasoning process. As an example, a smart lamp could learn home occupants habits and adapt off/on times or light intensity from what people are used to do; or a heating/cooling system could save a considerable energy by adapting its behaviour using data coming from proximity sensors, in order to turn on/off at the proper time, making the environment warm or cool, on the basis of human presence in the house. Including intelligence in a smart device implies to add, to the firmware, a proper support for the AI techniques needed in the specific project, which could range from first-order logic inference, to more complex reasoning, up to machine learning-based approaches. In particular, when a form of reasoning is required, state-of-the-art techniques consider the use of logic/declarative frameworks or languages which, in turn, are traditionally based on Prolog or Prolog-like envi- ronments; the bad news is that such runtimes are usually not able to execute on devices like MCUs that feature a limited computational power and available memory. However, we must remind that, in the field of high-level programming lan- guages/platforms for MCUs, the MicroPython project has gained a very high interest, since it provides a Python VM running over a wide range of MCUs, featuring very interesting run-time performances and a limited size memory foot- print. With these aspects in mind, the authors investigated about the possibility of porting a Python-based logic/declarative framework to MicroPython, thus al- Programming Intelligent IoT Systems with a Python-based Declarative Tool 3 lowing developers to include reasoners in IoT devices, making them “more intel- ligent”. The developed tool, called PHIDIAS, is able to support logic-based/BDI multi-agent systems in Python. PHDIAS is the evolution of PROFETA [11] and has the aim of providing, in a single framework, a knowledge system, a proce- dural system and a reactive system: altogether can be used to write rational agents that can not only react to events but also plan actions in order to proac- tively reach their goals. This paper describes the tool, reporting the syntax of the declarative language highlighting, in particular, the components that are specifically written for the MCU and that provide access to I/O peripherals and wireless communication modules. A case-study is also included, in order to let the reader understand the capabilities of PHIDIAS and its advantages in the context of intelligent IoT. The paper is structured as follows. Section 2 deals with related work. Sec- tion 3 presents an overview of PHIDIAS. Section 4 describes the components provided by PHIIAS for a MCU scenario. Section 5 describes a case-study of a domotic application. Section 6 concludes the paper. 2 Related Work The research on IoT intelligent systems reports a wide number papers, dealing with different scenarios and solutions. The author of [16] provides a global conceptual overview of the synergy of AI and IoT with emphasis on its application in robotics and automation; the paper also outlines a number of case studies (home automation, oil-field production, smart robotics, smart manufacturing, and smart factory). In [13] the authors present an architecture based on a distributed edge/cloud paradigm, which aims to let drones recognize objects during their flight, in order to balance benefits and cost of processing data at the edge, versus a central location. The reasoning models are trained in the cloud, then deployed as Docker containers and loaded into a shared repository, from which can be accessed by the edge components. In [15], the authors deal with classrooms under-utilization in a real university campus, by instrumenting classrooms with IoT sensors to measure real-time us- age, using regression learning algorithms to predict attendance, and performing optimal allocation of rooms to courses so as to minimize space wastage. The authors of [17] propose an approach to decompose a complex AI applica- tion into simplified distributed modules connected by using the IoT technology. The framework, called AItalk, allows a developer to easily add, to existing IoT applications, AI mechanisms such as regression models, automatic data collec- tion, real-time prediction, model training, etc. In the context of run-time executive or programming languages for MCU devices, there are indeed few solutions. In general, since MCUs are programmed in C, any C-based run-time is theoretically able to execute onto such platforms, unless the memory footprint of the resulting code and the amount of RAM re- quired is too much for the target device. As for C-based platforms, CLIPS [1] is 4 Fabio D’Urso, Carmelo Fabio Longo and Corrado Santoro a run-time that supports writing and execution of ruled-based production sys- tems by means of a LISP-like programming language and a data model based on “facts”; however, CLIPS, to run onto a MCU, must be properly ported by patch- ing some system-dependent parts (like those relevant to mass storage) and, while this work seems feasible, at the present the authors do not have a knowledge of such a porting project. In the context of symbolic languages (also with function- al/declarative philosophy), there are several implementations of LISP/Scheme; as just an example, uLISP [4] is porting of the language for many MCU-based boards, like Arduino, ESP8266, STM32, etc.; it is interesting since it has a small memory footprint and, since it is a standard LISP implementation, could serve as run-time environment for a symbolic reasoner or production system. As for imperative and object-oriented approaches, it’s worth of notice the solution pro- vided for the Java world which consists in the JavaME [3], a JVM profile, with a suitable class library, specifically designed to fit small/embedded environment; the solution is interesting, but (as reported on the web page) it is able to run only in high-end MCU devices (e.g. Cortex-M7, ARM11). Some hardware plat- forms, like the NodeMCU board [5], offer a Lua-based environment; while the solution is interesting, it suffers of the problem of a low spreading of Lua which, at the present, cannot be considered a mainstream language. A solution to run JavaScript on MCUs is provided by the Espruino project; it is a commercial project by a company which produces and sells STM32-based hardware plat- forms, also providing an open-source development environment that includes a JavaScript interpreter running on several MCUs [2]; the interpreter is able to run also on low-end devices and it will be one of the solutions that we will anal- yse in our future work. The Python-based solution is the one considered in this paper; the choice of this language relies on three main factors; first, the increas- ing popularity of the language itself, which is ranked first in 2019 [7]; second, the availability of our Python-based BDI system PROFETA [11]; and third the availability of MicroPython as an effective Python run-time for the majority of MCU-based solutions. 3 Overview of the PHIDIAS Platform PHIDIAS [6] is a multi-agent platform that let developers write multi-agent sys- tems using the Python language and the BDI paradigm. PHIDIAS1 is the evo- lution of PROFETA [11, 8] and is a knowledge-based system supporting Prolog- like inference and allowing the implementation of agent behaviour by means of reactive and proactive rules. Like PROFETA, PHIDIAS provides a declarative language that offers logic/declarative constructs that can be mixed inside Python code; this is made possible by exploiting the object-oriented features of Python, in particular operator overloading. With respect to PROFETA, PHIDIAS adds the possibility of expressing Prolog-like goals, the support for multi-agent envi- ronments, the interaction among agents via messages (also belonging to different 1 PHIDIAS is the acronym of PytHon Interactive Declarative Intelligent Agent System Programming Intelligent IoT Systems with a Python-based Declarative Tool 5 machines), the possibility of tying procedures to events (to combine proactiv- ity and reactivity), and some modifications to the declarative language syntax in order to make it simpler and more flexible. We report here an overview of PHIDIAS; readers interested in more details can refer to [6, 11, 10, 9]. 3.1 Basics of PHIDIAS Like any knowledge-based system, a PHIDIAS program is made of a data part, which is represented by several beliefs, properly defined by the developer ac- cording to application requirements, and a computational part made of a set of rules. The data part may also include Prolog predicates that, applied to the beliefs asserted in the knowledge base, can be used to derive new knowledge. As for computational part, the rules that constitute the agent program can be of three types: – reactive rules, they are executed as triggered by the occurrence of certain events, such as asserting a belief into or retracting a belief from the knowledge base; – procedural rules, they are executed when specifically invoked, as in clas- sical procedural system; – event procedures, they combine both the types above, i.e. they are pro- cedures that can invoked but wait for the occurrence of specified events in order to proceed with the execution of the relevant body. Each rule has a head, that can be either (i) the specification of an event occurring when a belief is asserted or retracted, or (ii) the specification of a procedure that can be properly invoked. Optionally, a rule can have a context condition part (which is syntactically indicated by the symbol “/”, i.e. subject to) specifying a predicate that must be true in order to execute the triggered rule itself; the predicate is a condition on values of parameters and/or the presence of one or more given beliefs in the knowledge base. The last part of a rule, which is syntactically specified with the “>>” symbol, is the list of actions that expresses the computation to be executed following the activation of the rule; an action may be the asserting/retracting a belief, invoking a PHIDIAS procedure, or invoking a user-defined action that is instead implemented in pure Python. In order to let the reader understand how PHIDIAS works, we describe, in the following, two toy examples with the objective of providing the reader with the basics of PHIDIAS syntax and semantics. The first example, the listing of which is reported in Figure 1, is a simple knowledge-based application: here, we are representing a world in which there are “students” that, sooner or later, become “graduated”; the rules of the pro- gram have the objective of keeping the knowledge consistent. As the figure shows, the first part of a PHIDIAS program is devoted to concepts and symbol decla- ration, i.e. beliefs, which are declared as subclasses of Belief (lines 5-6), and variables used in rules that must be declared using the statement def vars (line 7). Referring to the example, the student state, for a person X, is represented by 6 Fabio D’Urso, Carmelo Fabio Longo and Corrado Santoro  1 from phidias . Types import * 2 from phidias . Lib import * 3 from phidias . Main import * 4 5 class student ( Belief ): pass 6 class graduated ( Belief ): pass 7 def_vars ( " X " ) 8 9 + graduated ( X ) / student ( X ) >> \ 10 [ show_line (X , " is now graduated ! " ) , - student ( X ) ] 11 + graduated ( X ) >> \ 12 [ show_line (X , " is not a student " ) , - graduated ( X ) ] 13 + student ( X ) / graduated ( X ) >> \ 14 [ show_line (X , " is graduated and cannot be a student again " ) , 15 - student ( X ) ] 16 17 PHIDIAS . run ()   Fig. 1. An Example of a Reactive PHIDIAS Program the presence of the belief student(X) in the knowledge base; in a similar way, the action of becoming graduated is represented by the assertion of the belief graduated(X), but this is possible only if X is a “student”: if this is the case, belief student(X) must be retracted. This is represented by three reactive rules reported in Figure 1, respectively in lines 9–10, lines 11–12, and lines 13–15. The first rule states that, as soon as the belief graduated(X) (with X any) is asserted (the “+” symbol means that something has been added to the knowledge base), if the belief student(X) (with that X) is already present in the knowledge base, then the following actions are executed: first something is shown on the console and then belief student(X) is removed (since X is no longer a student). The second rule has the same triggering event of the first rule but it is evaluated only if the prevision rule does not match (i.e. the belief student(X) is not in the knowledge base) and the result is an error message and the immediate removal of belief graduated(X): indeed the sense is that it cannot exist a “graduated” that has not been previously a “student”. The third rule is instead used to state that, once a student has been graduated, s/he cannot become once again a student; to this aim, the rule is triggered by the assertion of belief student(X) and, if the knowledge base already contains the belief graduated(X), an error message is printed and the former belief is deleted. The second example is given in Figure 2 which reports the listing of a PHIDIAS program that uses procedures. Here we are supposing that this pro- gram is controlling a robot having the task of repetitively finding and grabbing balls that are present in the environment. We are using the belief BallPos(X,Y) to keep track of the position of (known) balls; the procedure CatchBall(), in lines 12–13, has, as contextual condition, the presence of (any) belief BallPos(X,Y) in the knowledge base; if this is true (variables X and Y will be bound to the relevant values), the robot is driven towards ball’s position (action GoTo(X,Y)), then the ball is picked (action GrabBall()) and the belief is removed from the knowledge base since that ball is no more present in the environment; finally, Programming Intelligent IoT Systems with a Python-based Declarative Tool 7  1 from phidias . Types import * 2 from phidias . Lib import * 3 from phidias . Main import * 4 5 class BallPos ( Belief ): pass 6 class CatchBall ( Procedure ): pass 7 class FindBall ( Procedure ): pass 8 class Goto ( Action ): ... 9 class GrabBall ( Action ): ... 10 def_vars ( " X " ," Y " ) 11 12 CatchBall () / BallPos (X , Y ) >> [ GoTo (X , Y ) , GrabBall () , 13 - BallPos (X , Y ) , CatchBall () ] 14 CatchBall () >> [ FindBall () , CatchBall () ] 15 FindBall () >> # ... a c t i v a t e c o m p u t e r vision system to find for the ball 16 17 PHIDIAS . run ( main = CatchBall ())   Fig. 2. An Example of a Procedural PHIDIAS Program the procedure CatchBall() is called recursively in order to let the robot pick the next ball. On the other hand, when the CatchBall() is called and no ball position is known (i.e. no belief BallPos(X,Y) is present, line 14), the procedure FindBall() is first involved and then CatchBall() is recursively called; here the FindBall() (which is not detailed in the listing) has the objective of activating a computer vision system which should search for the ball and then assert the relevant BallPos(X,Y) belief in the knowledge base. Apart from the functionality explained, the listing shows some important syn- tactical elements of PHIDIAS: beliefs, procedures and variable must be declared (lines 5–10), as it has been shown also in the first example, while Actions are basic elements that represents atomic computations that a PHIDIAS program can execute; in particular, they contains pure Python code (which is not shown in the figure) and constitute one of the pieces of the bridge that connects the PHIDIAS world with the Python world. Indeed, the way in which a PHIDIAS program interacts with the external world is supported by means of the two basic abstractions: Beliefs and Actions, which are described in the following. Beliefs represent input data and thus are generated by (Python) computa- tions that, by means of interaction with suitable software drivers, are able to gather/poll data; beliefs, in turn, can be used to within PHIDIAS rules, as trig- gers or simply data knowledge for procedures. In order to support data polling, and consequent belief generation, PHIDIAS provides a further abstraction rep- resented by the Sensor class: any piece of user software in charge of generating beliefs can be encapsulated in a Sensor sub-class, in particular in its sense() method; this code is executed by the PHIDIAS runtime in parallel to other ac- tivities2 , and thus can feature blocking calls and/or periodicity. In a similar way, any kind of output activity of a PHIDIAS program must be encapsulated into a user-defined Action (sub-)class and, in detail, in its execute() method that 2 each sensor has its own thread of execution 8 Fabio D’Urso, Carmelo Fabio Longo and Corrado Santoro can also receive the proper parameters from the call performed within the body of a PHIDIAS rule.  1 from phidias . Types import * 2 from phidias . Lib import * 3 from phidias . Main import * 4 5 class a_belief ( Belief ): pass 6 class go ( Procedure ): pass 7 8 class Sender ( Agent ): 9 def main ( self ): 10 go () >> [ + a_belief ()[{ " to " : " Receiver@dest - machine . mydomain " }] ] 11 12 Sender (). start () 13 PHIDIAS . run_net ( globals () , ’ http ’)    1 from phidias . Types import * 2 from phidias . Lib import * 3 from phidias . Main import * 4 5 class a_belief ( Belief ): pass 6 def_vars ( " X " ) 7 8 class Receiver ( Agent ): 9 def main ( self ): 10 + a_belief ()[{ " from " : X }] >> [ show_line ( " Received a belief from " , X ) ] 11 12 Receiver (). start () 13 PHIDIAS . run_net ( globals () , ’ http ’)   Fig. 3. Example of Two Communicating Agents in PHIDIAS 3.2 Multi-agent Systems in PHIDIAS One key aspect that distinguishes PHIDIAS from its predecessor, PROFETA, is the support for multi-agent systems. In PHIDIAS, a developer can define several agents, each one with its own set of rules, that are able to interact to each other; agents can coexist within a single PHIDIAS runtime environment, running concurrently, or execute in different environment/computer and thus interact by means of a communication network. Interaction among agents is performed by means of a message-passing mech- anism that allows a sender agent to assert a belief in the knowledge base of another agent; using this mechanism, the belief is transferred to the destination agent that, in turn, can react by using a PHIDIAS rule triggered by the assertion of that belief. From the syntactical point of view, as Figure 3 shows, sending a message implies to use the belief assertion statement which is annotated with a “to” tag that specifies the agent destination of the belief itself (see line 10 of Figure 3); addressing is performed using a classical naming scheme such as “localname @ Programming Intelligent IoT Systems with a Python-based Declarative Tool 9 machine-name-or-ip”. In a similar way (see the bottom side of Figure 3 and in particular line 10), by annotating a belief assertion trigger event with the “from” tag, the name/address of the sender agent (if any) can be retrieved and used properly. As for the underlying messaging mechanism, as the listings suggest (see line 13 of both listings in Figure 3), message transfer is performed by using HTTP: each PHIDIAS environment runs a HTTP server that receives beliefs properly encoded, identifies the destination agent and, if it exists, put the data into the relevant knowledge base, activating rules if any. 4 PHIDIAS for MCU Environments In the world of IoT and Smart Objects, a key aspect is the way in which data are received from and sent to the environment; this may include also data gathering from sensors (e.g. presence sensor) or actuator driving (e.g. driving a lamp), or commands/data related to the interaction with other devices. From the soft- ware point of view, such an interface has the task of providing an access to the I/O peripherals of the MCU, such as GPIO, timers, communication interfaces, etc., allowing a developer to use the proper abstraction which are related to the language/platform used to implement the application. To this aim, MicroPy- thon includes some modules that provide a suitable software interface to MCU peripherals, in particular: – General-Purpose Digital I/O lines; – PWM generation; – Analog-to-Digital Converters; – UARTs to support serial communication; – Serial-Peripheral-Interface (SPI) and I2 C Bus. It’s up to the developer to use such modules to integrate a specific sensor that could use e.g. ADC or I2 C interface, or one or more actuators attached to e.g. a PWM line or UART or another communication interface. This is the task of the porting of PHIDIAS for MicroPython: it includes a Python package, called phidiasmcu, that provides a set of services able to the perform a bridge between the PHIDIAS world and the Python/MCU world. In the current implementation, the services offered are GPIO, ADC and communication via TCP/IP over WiFi. GPIO services can be used to write an output line, to read an input line or to activate a notification when an edge is detected on an input line. To this aim, the API provided in PHIDIAS includes the following types: – OutPut(pin,value), it is a PHIDIAS action able to set the given line to a certain value (0 or 1); – InPin(pin,variable), it is a special PHIDIAS belief3 that binds the vari- able to the actual value of the given pin; 3 it is called ActiveBelief. 10 Fabio D’Urso, Carmelo Fabio Longo and Corrado Santoro – HandleInputPin(pin,edge), it is an action able to activate a trigger on the given pin according to the occurrence of a specified edge (either rising or falling); when the edge is detected the special belief4 PinEvent(pin,value) is automatically generated, which can thus be used to trigger a PHIDIAS rule. ADC services allow PHIDIAS programs to configure the analog-to-digital converter peripheral of the MCU, start conversions and retrieve obtained values. Two PHIDIAS types are available for this: – ADCSetup(pin), it is an action that can be used to configure the given pin as ADC input; – ADCRead(pin,variable), it is a special construct that (according to the way in which it is used) can act as a belief or an action; if it appears in the context condition of a rule, it acts as an (active) belief; if it is present in the body of a rule, it acts as an action; in both cases, the objective is to bind the variable to the ADC values sampled from the pin. As for communication services, there are several aspects that must be taken into account when a PHIDIAS program runs onto a MCU. Basically, MCU sys- tems do not possess the same networking/interconnection capabilities of a clas- sical computer system; indeed, communication mechanisms of MCUs are quite limited in characteristics and range, and include systems typical of the IoT world, like Bluetooth Low Energy, 6LowPan, ZigBee, etc. In some cases, it is possible to use small Wi-Fi modules that, while implementing the whole TCP/IP stack, present some limitations, like the ability to act only as client or the possibility of opening only one connection. PHIDIAS Environment PHIDIAS MCU TCP/IP HTTP Socket Message Gateway HTTP PHIDIAS BLE PHIDIAS Environment MCU HTTP PHIDIAS Environment Fig. 4. Message Gateway 4 it is a Reactor, i.e. a special belief that can generate a rule triggering event but is not added to the knowledge base. Programming Intelligent IoT Systems with a Python-based Declarative Tool 11 Given this, in porting PHIDIAS to a MCU environment, we had to rethink the communication aspects since the HTTP-based interaction, “as-is”, cannot be supported. But, at the same time, any other mechanism must not affect the syntax and the semantics of communication—from the language point of view— neither the naming scheme used for agent addressing. To this aim, we designed an architecture for the communication system for PHIDIAS in IoT environments, depicted in Figure 4, which is based on the presence of one or more Message Gateways, i.e. machines able to run a service that, on one side, exposes the HTTP protocol, behaving as a “classical” PHIDIAS environment and, on the other side, presents a connection endpoint that uses a specific protocol for the IoT environment. While the HTTP side is always the same for any kind of gateway, the other side depends on the protocol employed which, in turn, is tied to the hardware modules available on the IoT devices. In our current implementation, as it will be described in the case-study, we designed a Socket-based Messaging Gateway which is intended to be used with those Wi-Fi modules, often employed in MCU environments5 , that are limited to open only one TCP socket. In this case, a node running PHIDIAS connects to that gateway and handles message sending/reception through that single socket: it’s up to the gateway to interpret specified recipients and deliver the message to the right node/agent addressed.  1 from phidias . Types import * 2 from phidias . Lib import * 3 from phidias . Main import * 4 from phdiasmcu . gpio import * 5 from phdiasmcu . idw01m1 import IDW01M1 6 7 class presence ( Reactor ): pass 8 class setup ( Procedure ): pass 9 10 class Pr esenceSe nsor ( Agent ): 11 def main ( self ): 12 setup () >> [ Ha ndleInp utPin ( " A1 " , " falling " ) ] 13 + PinEvent ( " A1 " ,0) >> [ + presence ()[{ " to " : " lighter@livingroom - bulb " }] ] 14 15 sock = IDW01M1 () # Wifi module driver 16 sock . open ( baud =57600) # Connect to the WiFi network 17 sock . wait_wifi_up () 18 sock . connect ( ’ gateway . address ’ , 9999) # Connect to the Message Gateway 19 sock . send ( b ’ livingroom - sensor -1\ n ’) # a n n o u n c e node name 20 21 Pres enceSen sor (). start ( setup ()) 22 PHIDIAS . run_net ( globals () , ’ gateway ’ , sock )   Fig. 5. The PHIDIAS Code of the Presence Sensor 5 In particular, we are talking about the SPWF01SA Wi-Fi module [14]. 12 Fabio D’Urso, Carmelo Fabio Longo and Corrado Santoro 5 Case-Study In this Section we report a case-study which shows how to leverage PHIDIAS for the implementation of automated actions involving IoT devices in a domotic environment; it is a simple (but working) example, which however shows all the features of PHIDIAS in MCU/IoT environments. We focused on a system of smart light bulbs, grouped in rooms, where each rooms is equipped with one or more proximity sensor; the idea is to keep the lights on, according to human presence in a room, only for the needed time useful for home’s inhabitants, in the view of energy saving. We consider that each sensor and bulbs are small MCU devices, equipped with a Wi-Fi module, some digital I/Os and running, of course, MicroPython and PHIDIAS; here, sensors send, via PHIDIAS messaging, on/off commands to the bulbs which, in turn, implement a proper timer to switch off the light when no more people are in the room.  1 from phidias . Types import * 2 from phidias . Lib import * 3 from phidias . Main import * 4 from phdiasmcu . gpio import * 5 from phdiasmcu . idw01m1 import IDW01M1 6 7 class presence ( Reactor ): pass 8 class my_timer ( Timer ): pass 9 10 class lighter ( Agent ): 11 def main ( self ): 12 + presence () >> [ OutPin ( " B0 " , 1) , my_timer (60000). start ] 13 + timeout ( " my_timer " ) >> [ OutPut ( " B0 " , 0) ] 14 15 sock = IDW01M1 () # Wi - fi module driver 16 sock . open ( baud =57600) # Connect to the Wi - Fi network 17 sock . wait_wifi_up () 18 sock . connect ( ’ gateway . address ’ , 9999) # Connect to the Message Gateway 19 sock . send ( b ’ livingroom - bulb \ n ’) # a n n o u n c e node name 20 21 ligher (). start () 22 PHIDIAS . run_net ( globals () , ’ gateway ’ , sock )   Fig. 6. The PHIDIAS Code of the Smart Bulb Figure 5 shows the code running in each sensor of the room. Here we are considering that the hardware device that detects people presence has a digital interface and is connected to the input pin called “A1” of the MCU: the line is normally set to logic “1” and each time a movement is detected in the room, it goes to “0” keeping that state until a rest of at least 3 seconds is identified. On this basis, we have an agent called PresenceSensor that detects the edge generated by the sensor and sends a proper message to the bulb; in particular, the setup() procedure (line 12) activates a trigger on that line when a falling edge is detected: if this is the case, the PinEvent() belief is asserted and the rule in line 13 is triggered thus provoking a message sending to the smart bulb; Programming Intelligent IoT Systems with a Python-based Declarative Tool 13 here, the destination agent specified is ligher@livingroom-bulb, i.e. the agent named “ligher” running the node named “livingroom-bulb”. Lines 15–19 report the code needed to perform connection to the messaging gateway: here first the driver of the Wi-Fi modules is created which waits for the network, then performs connection to the gateway and announces its node name (“livingroom-sensor-1”). Lines 21 and 22 start the agent and the PHIDIAS runtime. On the other side, the smart bulb runs the PHIDIAS code reported in Fig- ure 6. Here we are supposing that the lamp is connected to the digital output line named “B0”; apart from the libraries used to drive digital outputs, this example uses timers which are natively provided by the PHIDIAS library. The startup code (lines 15–22) is the same to that of the sensor while the agent, named “ligther”, has only two reactive rules: the former, line 12, is executed when the presence() belief is asserted: it is indeed activated to the message sent by the presence sensor; the body of the rule turns on the lamp through action OutPin() and starts a timer for 60 seconds; if the timer elapses the timeout() belief is generated and rule in line 13 is triggered, thus turning off the lamp; but if an- other presence() belief is received, due to activation of the presence sensor, the timer is restarted. 6 Conclusions This paper described the MicroPython implementation of PHIDIAS, a BDI sys- tem that lets a developer write logic-based intelligent multi-agent system. The use of MicroPython allows the tool to run onto MCU-based hardware platform thus making it ready for the Internet-of-Things world. The implementation in- cludes a set of libraries that provide suitable software abstractions for the various peripherals that usually are present in a MCU, as well as a messaging middle- ware to let agents interoperate transparently and independently of the running platform, i.e. MCU system or classical CPU system. A case-study has shown the basic capabilities of PHIDIAS that are provided for a MCU/IoT environment. Our future work aims at writing more intelligent IoT application, in order to assess the characteristics of the tool for the specific context, and write additional libraries and drivers for other peripherals and/or sensors and actuators. References 1. C language integrated production system (2017), http://clipsrules.sourceforge.net/ 2. Espruino javascript interpreter source code (2019), https://github.com/espruino/Espruino 3. Java micro edition (2019), https://www.oracle.com/java/technologies/javameoverview.html 4. Lisp for microcontrollers (2019), http://www.ulisp.com/ 5. Nodemcu (2019), https://www.nodemcu.com/index en.html 6. Phidias web page (2019), https://github.com/corradosantoro/phidias 7. Popularity of programming language (2019), http://pypl.github.io/PYPL.html 8. Profeta web page (2019), https://github.com/corradosantoro/profeta 14 Fabio D’Urso, Carmelo Fabio Longo and Corrado Santoro 9. Fichera, L., Marletta, D., Nicosia, V., Santoro, C.: A methodology to extend im- perative languages with agentspeak declarative constructs. In: Proceedings of the 11th WOA 2010 Workshop, Dagli Oggetti Agli Agenti, Rimini, Italy, September 5-7 (2010) 10. Fichera, L., Marletta, D., Nicosia, V., Santoro, C.: Flexible robot strategy de- sign using belief-desire-intention model. In: Research and Education in Robotics- EUROBOT 2010, pp. 57–71. Springer (2011) 11. Fichera, L., Messina, F., Pappalardo, G., Santoro, C.: A Python Framework for Programming Autonomous Robots Using a Declarative Approach. Sci. Com- put. Program. 139, 36–55 (2017). https://doi.org/10.1016/j.scico.2017.01.003, https://doi.org/10.1016/j.scico.2017.01.003 12. Savaglio, C., Ganzha, M., Paprzycki, M., Bdic, C., Ivanovi, M., Fortino, G.: Agent- based internet of things: State-of-the-art and research challenges. Future Genera- tion Computer Systems pp. 1038–1053 (2020) 13. Seraphin B. Calo, Maroun Touna, D.C.V.A.C.: Edge Computing Architecture for applying AI to IoT. In: IEEE International Conference on Big Data (BIGDATA). IEEE (2017) 14. STMicroelectronics: Command set reference guide for ”AT full stack” for SPWF01Sx series of Wi-Fi modules. WWW (2018) 15. Thanchanok Sutjarittham, Hassan Habibi Gharakheili, S.S.K., Sivaraman, V.: Ex- periences With IoT and AI in a Smart Campus for Optimizing Classroom Usage. In: IEEE INTERNET OF THINGS JOURNAL, VOL. 6, NO. 5, OCTOBER 2019. IEEE (2019) 16. Tzafestas, S.G.: Synergy of IoT and AI in Modern Society: The Robotics and Automation Case. Robot Autom Eng J. 2018; 3(5): 555621. (2018) 17. Yun-Wei Lin1, Yi-Bing Lin1, C.Y.L.: AItalk: a tutorial to implement AI as IoT devices. IET Netw., 2019, Vol. 8 Iss. 3, pp. 195-202 (2019)