About “jIoT” Project
Hello everyone, let me in a short description present my own approach to home automatization - jIoT. TLDR - I’m using Cayenne MQTT API to bring in my own device (literaly) and even aproaches. The “BIG” idea of the project is that not only “physical” device can be connected, but also programs/PCs etc can be connected to jIoT. Basically whole logic of the program is moved to local RPI and Cayenne web is (ab)used just as a presentation layer.
Motivation
I’ve been working on similar IoT project by my own for a couple of months. Even everythink works just fine my project suffers by simple “web application” implementation. When I saw Cayenne with open MQTT API I have got an idea to connect my previous (kinda modified) project with Cayenne. That’s ultimate reason why the whole project is little bit different.
I’ll skip some template topic
I hope you won’t be too upset when I skip some topics from the template and add some new chapters. I believe that they will better reflect the whole project.
Pros and Cons
As I found (as many of you) Cayenne interface for triggers and alerts amazingly easy to use, I believe there are some Cons which I tried to enhance. For me there are primary 2 cons which I tried to eliminate:
- Cloud location - even it might look like an advantage, I believe it is not. The fact that all the “logic” is performed in a cloud adds latency, which might not be good for some “If - Than” actions which needs to be performed as quick as possible i.e. “If motion - turn on light”. With bad latency, you might be out of the dark room, before the lights turned on. In addition all this actions/triggers are strongly depended on your Internet connection (even you don’t believe it there is no such way as 100% uptime)
- Limited possibility - “IF - THAN” period. For now there is no possibility to improve this behaviour. I’ve seen lot of feature request which calls for the improvment of this option.
To eliminate these “Cons” I’ve created something I’m callingPolicy(will be explained later on).
Although I tried to improve some features of Cayenne, there is one limitation of my project - as the currrent version of Cayenne mobile app doesn’t support MQTT device (even I don’t know why) we need to wait for such a update.
What’s Connected
- LED every marathone starts with single step and every IoT project starts with connecting the single LED so as mine.
-
HW button simple HW button which can be used in
Policiesas input signal (it uses interrupt ofRPI). -
Motion PIR sensor once again no magic here. What worth to mentioned is, the PIR sensor uses RPI interrupts which can be easily and in real time used in
jIoTpolicies. - Temperature sensor DS18B20 simple 1 wire temperature sensor connected to RPI.
- LDR light sensor as ability to measure sunshine and darkness simple LDR and Capacitor is connected.
- Light Strip RGB led strip which support to change color and brightness. Actions like dimming (out|in) are hard coded to LED strip driver.
- BlueTooth sensor internal RPI3 bluetooth module is used to track home activity of the person. Based on this we can build policy which are coupled with presence of the individual people.
- IP Speed Checker this “checker” simple ping given IP and presents its avarage speed value to the Cayenne cloud.
- IP availability very simillar checker as previous one, the returned value is just “up” or “down”.
- PC availability of the PC. Currently written driver defines basic actions such as “on” and “off”
- Music Player we can track if Music is playing or not. There is possibility also to start or stop Music.
Triggers & Alerts
As it was mentioned in previous section Pros and cons there are no Cayenne Triggers & Alerts used.
Scheduling
As it was mentioned in previous section Pros and cons there are no Cayenne Sheduleres used.
How jIoT architecture works?
Now the fun begins - let’s roc’n’roll. All Architecture is design to be as modular as possible and represents so called Policy Based Driven architecture. The Core of the arch. just defines basic algorithms such as update data (local and to Cayenne cloud), implements MQTT API, defines local variable and local actions. The most important part of Core of the jIoT is to handle so called drivers.
As the name says driver is simple .py library which says jIoT how to handle current “connected device” (stay tuned it doesn’t need to physical connected to RPI). Each driver is supposed to implement given itnerface - and so we are sure at least one action - status is defined. Moreover each device can define as many actions as required. All this devices can be dynamically used in Policy config file.
Special Actions
As every device might defines its own actions there are some special actions defined by Core which can be already used in Policies. Currently defined `actions:
- EmailSend email can be send to particular recipients
- PlayFile sound file can be played
-
RunRemoteCommand remote command can be executed (
fablibrary and.ssh/configare used) -
SetGlobal global variables can be set in
Policiesto enhance behaviour of thePolicies -
Tts simple text is played to user via
pico2wave
Special Variables
In Policies you can of course use current values of connected devices. In order to enhance this behaviour I’ve implemented some internal variables which can be used in Policy configuration.
-
hour returns
strftime("%H") -
minute returns
strftime("%M") -
dayOfMonth returns
strftime("%d") -
dayOfWeek returns
strftime("%d") - weekend returns True if is weekend otherwise False
Policy
Policy is one of the main component of the whole Architecture. It represents my own enchancement of Cayenne triggers. Basically Policy contains one or more Condition coupled with one or more action. It enhances the triggers mainlny in various way:
-
More than one condition here is no limit for how many conndition will trigger the action/s. The important fact is ALL POLICIES need to be True in order to trigger action/s. In other words there is logical AND between
Conditionsin particularPolicy. OR logic can be achieved by combining multiple policies. -
More than one action the same simple rule is also True for
actionscoupled toPolicy- more than oneActioncan be triggered ifcondition/sare met. - Different type of Policies as there are many different situations when the particular Policy can be triggered also 2 type Policies are defined:
- lazy Policy - this Policy will be triggered when it is True defined times in a row. As simple as that you would like to implement such a Policy in order to avoid simple spike. This kind of Policy can be also defined as one time. One time Policy will run only once and than again when it reach bellow defined treshold.I.e. typycal usage for such a Policy will be alert when teperature will goes above specified limit. Then Polivy will wait i.e. 3 “rounds” (can be defined) and when it is still about specified limit - action will be triggered. When one time atribute is set it will be triggered only once (it could be anoying to receive email every minute than temperature is above certain limit). One time Policy will be triggered again when temperature goes bellow specified limit and raise again.
- instant Policy - Policy will run imediately with no waiting. This kind of Policy can be used for alarm for example when nobody would like to wait 3 rounds of measuring.
I believe one example will explain more than thousends words:
"p1" : {
"conditions" : [ ["m1","==","1"],
["bt1","==","0"]
],
"actions" : [{"J":{"EmailSend" : {"to":"zandar@protonmail.ch","text":"Damn some is home!!","subject":"You should better call police!"}}},
{"ls1" : {"panic_blicking" : {"freq": "30", "time":"10"}}},
{"J" : {"PlayFile" : {"filename": "alarm.wav"}}}
],
"type" : "instant",
"cnt_limit" : "3",
"onetime" : "True"
}
I’ll let you gues what this Policy p1 is served for 
Another Policy definition example:
"p2" : {
"conditions" : [ ["bt1","==","1"]
],
"actions" : [{"ch1":{"status" : {"value":"1"}}},
{"J":{"Tts" :{"text": "Welcome home Michal."}}}
],
"type" : "lazy",
"cnt_limit" : "3",
"onetime" : "True"
}
Conditions definition
Conditions definition are using Python syntax. They contains ["name of device/variable","condition","value"]. There might be defined multiple conditions and they are processed in order in such they are defined. Once more time please keep in mind logical AND is applied between particular Policies.
Actions definition
All actions defined in actions section will be triggered when ALL defined conditions are True. Action definition looks like {"device name" : {"action of the device" : {"parameters pass to action" : "paramter value "}} }. There is only one special device defined - J. This device represents Core functionality and its actions defined.
At the very botton of the Policy we can see Policy type definition.
Config files
There are 2 configuration files which are used acros the whole project. json format is used for configuration file definition.
-
p.config- snippet of this file is already presented inPolicysection -
j.config-corefunctionality is defined in this config file - such as MQTT credentials. Also “connected devices” are defined in this configuration file. Although each configuration part of the devices is unique there are some part which are common. Please see commented snipped:
"J":{
# MQTT details from Cayenne
"base_topic" : "mqtt-base-topic-here"
"username" : "mqtt-username",
"client_id" : "mqtt-client-id"
"password" : "mqtt-password"
# actions provided by `Core`
"actions" : {
"EmailSend" : {"name":"SendEmail", "description":"Sending email."},
"Tts" : {"name" : "Text to speech", "description":"TTS using pico2wave module."},
"PlayFile" : {"name": "Play attached file", "description":"Simple playing using aplay"},
"RunRemoteCommand" : {"name": "Run remmote command", "description":"Just run remote command."}
}
},
# bluetooth device definition
"BlueTooth" : {
"name":"bt1", # this name needs to be used in Policies
"description":"shot descpr.",
"actions": {}, # already not used
"hwaddress" : "7C:91:22:CE:C4:54", # HW address which device will search for
"mqtt_channel" : "0", # which mqtt channel will be used to upload data do Cayenne
"mqtt_data_type" : "motion,d" # data type from Cayenne point of view
},
"IpCheck" : {
"name":"ip1",
"description":"check whether zandars pc is up",
"actions": {},
"ipaddress" : "192.168.25.8", # IP addres which device will search for
"mqtt_channel" : "1",
"mqtt_data_type" : "motion,d"
},
Some Pics
Dashboard Screenshots
Conclusion
Current state of the development is that the Architecture is currently in beta state, but I believe it is “ready to use”. I plan to work on current idea and even expand it even further. If I forgot to explain some crucial part, please don’t hesitate to write any questions in comment bellow. I will try to my best in answering.
Future
It all depends. As I mentioned the whole Architecture/idea/project will only grow and once I believe it will take place in my home automatization (i.e. currently I’m looking for way to connect my blindes to jIoT). If there will be interest there is no problem to share code on github and prepare steps for installation/using.
Thank you for any comment.
Y
