jIoT - home automatization


#1

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 calling Policy (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 Policies as input signal (it uses interrupt of RPI).
  • 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 jIoT policies.
  • 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 (fab library and .ssh/config are used)
  • SetGlobal global variables can be set in Policies to enhance behaviour of the Policies
  • 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 Conditions in particular Policy. OR logic can be achieved by combining multiple policies.
  • More than one action the same simple rule is also True for actions coupled to Policy - more than one Action can be triggered if condition/s are 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 :slight_smile:

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 in Policy section
  • j.config - core functionality 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


Subscribe to topic on another device
#2

Hi @michal.z4nd4r,

Thank you for posting this! I’m currently at Maker Faire Bay Area, so not keeping as up to date with the Cayenne forum posts like normal. This is a cool and interesting project, I have not seen one like it yet.

-Benny

@eptak @croczey @asanchezdelc1 @kreggly @adam check this out.


#3

Hi Benny (@bestes),

Yeah I though my project will be kinda different :slight_smile: I really enjoy you like it. Let’s hope for some audience and constructive discussion and whole project can be moved to another dimension :slight_smile:

Y


#4

Wow, that was quite the write-up! I like a lot of the trigger features you explained, and I hope most of it gets added in to the trigger re-write that is coming soon. One suggestions I do have is using Cayenne for your non-urgent triggers, especially things like emails, text messages, etc. It shouldn’t matter much if those are delayed even up to a minute, as sometimes they will be delayed this much just by the providers of the services.


#5

@adam thank you for your comment. Well that will be great if the features of my re-written triggers become implemented. Well the using Cayenne and local Policies would bring just a mess - as you have 2 places for your “logic”. As you can imagine it is not a big deal to send emails, so there is no problem to send them directly from Policy.


#6

New features are upcomming

There are new feature upcomming - get status about your devices/sensors directly from facebook through facebook bot. I’ve also implemented basic NLP and NLU (through wit.ai).

I will update the post/create new one soon (I believe). Stay tunned.

Y


#7

@adam @bestes - hello guys how it is going? As I could see there is REST API comming - great opportunity to use it in my project, with facebook bot - get status about your project/device values directly from facebook, what do you think about it?


#8

I think it’s a great idea, can’t wait to see it!


#9

Yeah, great idea. We’ll let you know as soon as API is available for Beta testing too!

-Benny


#10

Hello @adam, @bestes ,

well the bot itself is actualy working. I’m just waiting for REST API to be published.

Check it out:

Y


#11

I love your local Policy concepts, I definitely see use for them, especially if our sensors/gateways/brokers lose internet connections or network connections.
The analogy I like to use is “what if we lose communication with head office, what now??” Having local policies ensure that the system still functions, does not have to wait for higher “decisions”.
Great job!!