An open API service indexing awesome lists of open source software.

https://github.com/edward62740/firebase-ingestor-rs

CoAP <-> Firebase bridge for IPv6 IoT devices
https://github.com/edward62740/firebase-ingestor-rs

coap firebase rust

Last synced: about 1 month ago
JSON representation

CoAP <-> Firebase bridge for IPv6 IoT devices

Awesome Lists containing this project

README

          

# Firebase Ingestor

Firebase requires REST API over HTTPS which is too expensive for many power constrained IoT devices.

This project allows for low-power IoT devices to read/write data in a Firebase RTDB instance, by forwarding CoAP messages from the IoT devices.

**IoT Device** <--- *CoAP* ---> **Firebase Ingestor** <--- *REST API* ---> **Firebase**

The ingestor does three things:
- Advertises a service over DNS-SD (RFC 6763) along with its IP address, to be discovered by the IoT device at runtime
- Sets up a CoAP server bound to the abovementioned IP, for the IoT device to post data
- Forwards received CoAP data to Firebase


The executable can be run with the following arguments:
```
firebase-ingestor-rs.exe [--no_metadata][--no_struct]
```

This project is used with IPv6 Thread networks.

However, this program is expected to function on a IPv4 LAN outside of the Thread network, so NAT64 (RFC 6146) may be needed to communicate from IPv6 IoT devices.

Accepted CoAP payloads are in the form `/path/../to/field:value,...,field:value` for POST/PUT.
Hence, it is recommended that there is some network layer encryption. PUT is generally preferable, as POST will nest the entire data structure inside a parent node with randomly generated key.

The CoAP payload is pushed to Firebase and takes on the format below. The actual data is nested inside a parent node "data", along with other metadata generated by this program.
To disable the metadata generation, provide the optional argument `--no_metadata`. Note that the "data" parent field is strictly necessary unless the argument `--no_struct` is given (otherwise the data will just be dumped into whatever path was given), and may have any number of leaf nodes.
```
/path/ [ ]
|
└─── to/
│ │
│ └───data (optional parent)
│ | {field : value}
│ | {field : value}
│ | ...
| └───Ipv4 (optional)
| └───Unix timestamp (optional)

...

/path/ [ --no_metadata --no_struct ]
|
└─── to/
│ │
│ └───{field : value}
│ {field : value}
│ ...

```

For GET, use the form `/path/../to/` , which will return the data fields under `to/` (i.e. field:value,...,field:value).

For DELETE, use the same form as GET, and the entire subtree is recursively deleted.