1:wq
erlyThing is a decentral, distributed message based thing plattform written in Erlang.
- decentral system.
- distributed system which communicate over messages
- starting and stopping of things during runtime
- configuration of messages which a thing understands
- dynamic handling of config files (things.config and messages.config)
- Integration of 3rd party applications is simple.(see cuberl)
- Generic way of handling rules (see funrunner)
- very easy DSL (Prototype)
- Logging. Every node writes their own logs. You can have a look throw the logging ui,
- internal monitoring system:
- webbased application explorer
- webbased process explorer
- list of all nodes in a network (alive or dead)
- systen information of a node
erlyThing consists of the following core applications:
- roni app for services which are used by several other services
- sue app for finding nodes and a interface for etop, sys_info, memory and others
- moni ui for sue based on web machine and erlydtl
- horst the runtime for the things
- leni ui for horst
extra application
- cuberl is an integration app for the Max! Cube product.
To install erlyThing on your machine, do the following steps :
Before you install erlyTHing on your machine, you have to install an erlang R16 runtime. After installing the runtime, you have to install rebar on your machine. rebar is the build tool for erlang.
- erlang R1603
- rebar the build tool for erlang
$ git clone https://github.com/ulfa/erlything
$ cd erlything
$ make
$ ./dev.sh
When you start erlyThing the first time, you get an error message Please, configure the path to the sources : enoent This message occurs, because erlbuild is not configured.
There are two options now:
- remove the erlbuild app from the dev.sh
- configure the path for the application
Edit the dev.sh and remove the part -s erlbuild
Edit the file apps/erlbuild/src/erlbuild.app.src
Exchange the existing path entries with the following ones
{src_dir, "./apps/horst/src"},
{dtl_dir, "./apps/leni/templates"},
{compiler_options, [{i, "./apps/horst/include"}, {outdir, "./apps/horst/ebin"}, {parse_transform, lager_transform}]},
{erlydtl_options, [{compiler_options, []}, {out_dir, "./apps/leni/ebin"}]},
After saving the file you have to compile again.
When erlyThing is up and running you can check it with : moni and if you want to see your deployed things you can use : leni In leni you can navigate to the System Logger and you will find the message that the system is started. You will also receive messages when a thing is stopped and when the thing is started.
After you did the steps as described in the previous section you also have to do :
make rcswitch send
- lager a logging framework
- gpio sysfs GPIO port driver and erlang module
- erlcron Erlang cronish system
- wiringpi a GPIO access library written in C for the BCM2835
- Adafruit_DHT
- rc-switch library to operate with 315/433 MHZ remote control devices
- streamer record audio and/or video
- and others
- DHT22 temperature-humidity sensor
- hc_sr501 PIR motion sensor
- TK0460 433Mhz RF Transmitter
- Max! Cube a heating system
I will add more in the future...
What is a thing?
A thing can be an actor or a sensor. In my world, an actor is something which understands specific messages, which a described in the messages.config. A sensor is something, which sends a specific message in the network. If there is an actor, which understands the message, then something will happen. ...maybe
This configuration file contains the things, which you want to use in your env.
{thing, "Temperatur_Sensor",
[
{type, sensor},
{driver, {dht22_driver, call_sensor}, []},
{activ, false},
{timer, 0},
{description, "Temp sensor in my office"}
]}.
Type | Value | Description |
---|---|---|
thing | Name of the thing | must be unique in a node |
id | The id of a thing | If the id is missing, the system will take "default". |
ets | true/false | should we use an ets or the thing state (for more see the documentation) |
icon | "/images/" and the name of the image. | The image must be placed in the apps/horst/priv/images/. |
type | sensor / actor | type of thing (actor or sensor) |
driver | {Module, Function}, [] | the list contains driver specific paramter |
activ | true / false | the thing will only be started if activ = true |
timer | int | if the driver needs timmer triggering, you must spec it here |
descripition | String | a description |
This configuartion file contains the drivers and the messages which they understand
{{dht22_display_driver, "default"}, [{<<"horst@raspberrypi">>,<<"dht22_driver">>, <<"default">>}]}.
You can read the line as : The thing with its implementation dht22_display_driver and id "default" will listen to messages which comes from the node "horst@raspberrypi", thing with an implementation module dht22_driver and id (version) "default".
Note: listen means that the thing will receive the message and if he can handle the message, it will process the message.
The following things (driver) are an example of how to implement a thing. These things are used in my internal project and they work for me.
- mail_client driver sends a mail
- usb_cam_driver makes pictures
- seven_eleven_driver play the seven eleven melody
- message_count_driver stores 20 messages and the overall count of messages
- cron_driver a cron thing.
- dht22_driver the sensor thing which triggers the dht22 sensor
- dht22_display_driver stores 20 values of the dht22
- transmitter_433_driver sends a signal via the transmitter to a switch
- boxcar_driver is an actor which sends messages to a boxcar client
- cube_driver integrates the Max! Cube
- funge_driver is an application which informs you if you run in trouble with fungi
- os_driver takes data of your system like cpu temp and load and sends them to the os_display_driver
- funrunner is generic way to create rules for consuming and sending messages
- sample_driver is an example
- reloader_driver is for development. Everytime you make an update of modules the reloader will load them into the system.
- boxcar_driver sends messages to your boxcar account
- cuberl is an application which integrates the Max! Cube from eq-3
- fungi_driver is an application which warns you if one of your rooms is fungi endangered.
- node_driver gets informed when a node is down or gets started
- mqttc_driver can send messages to mqtt broker like http://www.mqttdashboard.com/
- mnesia_driver persists messages and restore them if the node must be restarted (a kind of Event Sourcing)
- config_driver can send a thing configuration to another node, so that this config will be stored there (sending of the messages.config part is missing, so you have to edit the messages.config by hand)
- photocell_driver measures the lightness and send a message with the measured value. The actor which receives the message can decide what action will be triggered. (Setup will be described in the wiki)