orchestracities / lego-diorama-usi-2022 Goto Github PK

instead of passing the topic as variable, let's compose it inside the code following fiware protocol

a topic will be formed by:

• protocol (share across multiple sensors)
• service_api_key (share across multiple sensors of the same time, e.g. streetlights)
• sensor_id (different for each sensor)

a topic to read/write sensor values will be as follow: /<protocol>/<service_api_key>/<sensor_id>/attrs

i.e. supposed that the protocol is json, the service api key is 4jggokgpepnvsb2uv4s40d59ov and the sensor is urn:streetlight:001: /json/4jggokgpepnvsb2uv4s40d59ov/urn:streetlight:001/attrs

a message to update attributes is a json payload serialized as a string that maps attribute names to values:

{"attribute_name": "value"}

e.g.:

{"h": 70, "t": 15}

i.e., updating the sensor values will be a mqtt command as:

$ mosquitto_pub -t /json/4jggokgpepnvsb2uv4s40d59ov/urn:streetlight:001/attrs -m '{"h": 70, "t": 15}' -h <mosquitto_broker> -p <mosquitto_port> -u <user> -P <password>

a topic to receive commands will be as follow: /<protocol>/<service_api_key>/<sensor_id>/cmd

i.e. supposed that the protocol is json, the service api key is 4jggokgpepnvsb2uv4s40d59ov and the sensor is urn:streetlight:001: /json/4jggokgpepnvsb2uv4s40d59ov/urn:streetlight:001/cmd

a message to receive command is a json payload serialized as a string that maps command names to passed parameters and their values:

{ "command name": { "command parameter":  "value" } }

e.g.

{ "light": { "switch":  "on" } }

last, but not least, once a sensor receive a commands and execute it, it should confirm the execution (or report error) on the topic: /<protocol>/<service_api_key>/<sensor_id>/cmdexe

i.e. supposed that the protocol is json, the service api key is 4jggokgpepnvsb2uv4s40d59ov and the sensor is urn:streetlight:001: /json/4jggokgpepnvsb2uv4s40d59ov/urn:streetlight:001/cmdexe

the message to be sent is a json payload serialized as a string that maps attribute names to values:

{ "command name": { "command parameter":  "value" } }

e.g.

{ "light": { "switch":  "ok" } }

• monitor mqtt queue (1 topic for streetlight or for street)
• if message received "turn on light" turn on light
• when command succesfully applied send message "light on" in the topic (same as above)

• collect data from sensors
• send data to ttn

(see old code)

Is your feature request related to a problem? Please describe.

Given that we are not yet ready for the k8s + kubeedge stack, let's start with basic integration at the service level
by providing a docker ministack.

Describe the solution you'd like

deploy a stack with one click that includes different services required:

• iot agents
• context broker
• mongo
• ql
• timescale
• grafana

Describe alternatives you've considered

N/A

Additional context

N/A

• when sensor detect something (proximity)
• send message parking spot occupied
• turn on red light (closed loop)
• when sensor detect nothing
• send message parking spot free
• turn on green light (closed loop)

use a mqtt queue, 1 topic per sensor (2)

the flow should be:

1. subscribe to command topic
2. when command received to turn on light (e.g. { "light": { "power": "on" } }):
   1. turn on lights (a leave them on - the off control will be done with an external logic that ask to turn off)
   2. send ack to cmdexe topic (e.g. { "light": { "power": "ok" } })
   3. update status attribute on attrs topic (e.g. { "powerState": "on" })
3. when command received to turn off light (e.g. { "light": { "power": "off" } }):
4. turn off lights
5. send ack to cmdexe topic (e.g. { "light": { "power": "ok" } })
6. update status attribute on attrs topic (e.g. { "powerState": "off" })

• when sensor detect something (proximity)
• send message parking spot occupied
• turn on red light (closed loop)
• if charging button pressed (and sensor detect something), blink red light for 10 seconds (then again static red)
• when sensor detect nothing
• send message parking spot free
• turn on green light (closed loop)
• use a mqtt queue, 1 topic per sensor (2)

• deploy microk8s and register pi as kubedge node
• deploy docker container from the scenario on pi using kubedge
• deploy docke mqtt broker on microk8s node

• collect data from sensor
• send data to ttn

(see old code)

• read ir sensor movement
• send reading to mqtt topic (1 topic per sensor / topic should be configurable for each sensor)

Waste Management

• 1 seeeduino lorawan
• 1 Proximity sensor (HC-SR04)
• 1 Temperature & Humidity sensor (DHT-22)
• 1 Flame sensor (YG1006)
• 1 Accelerometer (MMA7660FC)
• 1 grovepi board for arduino1

Environment Management

• 1 seeeduino lorawan
• 1 Sound Sensor
• 1 UV Sensor
• 1 AirQuality sensor (BME680)
• 1 Gas Sensor
• 1 grovepi board for arduino1

Parking and EVCharging

• 1 Raspberry Pi 3 Model B
• 2 Proximity Sensors (HC-SR-04)
• 4 Leds (Red and Green, for parking and for ev-charging)
• 1 Button
• 1 grovepi board for pi3

TrafficFlow and Streetlight

• 1 Raspberry Pi 3 Model B
• 1 VCNL 4010
• 1 IR Obstacle Sensor
• 8 Leds (4 for each sensor)
• 1 grovepi board for pi3

Other items:

• Wires

• ultralight iot agent
• orion contex broker
• lorawan iot agent
• quantumleap
• timescaledb
• grafana