Some of the comments from the first experiments with set

Od samm

Dne 2015-08-02 10:12 Hlasů 1

1. Hardware (both dongle and all sensors) works pretty well and stable.
2. I started to write my own daemon to control all the staff (jablod :)). I want to separate part which works with hardware (and logging everything to db) with logical part. Now it is in a very earyly stage.
3. Syntax of the TX command is very limited (only 2 controllable outputs is not enough). May be it would be great to have some kind of "virtual bases" (e.g. TX0 TX1 TX2 TX3, etc) and pair devices with different "virtual" subdongles on the same USB slot? Does it possible from hardware point of view? If implemented this could be a good workaround.
4. Also i would recommend some basic authorization with dongle (e.g. pin based) + to send dongle serial in the "WHO AM I?" to support > 1 dongle at time if needed.
5. It would be great to have > 1 COM port with one used only for status updates from devices and another - for programming. This way it is implemented in every GSM modem and it allows to avoid situations where status updates are mixed with command responses + different ports can be opened by different programs.

I am planning to share all my work on github when it will be in a usable state.

Od linker

Dne 2015-08-02 12:50 Hlasů 1

I just finished basic python daemon for communication with dondle. It's very simple and stupid, but working:
https://github.com/trusnak/turris_gadgets_deamon
You need to update devices hash with your own serials to make it working.
Enjoy :)

Od samm

Dne 2015-08-02 14:56 Upraveno 2015-08-02 17:44

Thank you, will look on it. However i am thinking about a little more complicated system where all the data stored in SQLITE (or other sql-engine). Now i started to think about technical requirements at https://github.com/samm-git/jablodaemon/wiki .

Currently i think it will be something like:
1. There will be daemon which reads/writes to the serial port and updating events table. Also every update can trigger some functions to update device_table summary, trigger some alerts and write something to the queue table.
2. Another subprocess may read queue and trigger writing to serial port when needed.
3. Web interface could be a separate process which just reading sqlite db to present results for the web browser (or API?).

Now i am trying to understand all my requirements to such system before i will actually start coding. But i dont feel that it will be something overcomplicated and hard to implement.

Od linker

Dne 2015-08-02 15:58

Putting all info to database looks like good idea, but every sensor have different events and different logic. Some of them have battery some don't, some have a tamper event, etc. It could be tricky to find reasonable model to handle it all. That's why I'm looking at it different way:
- have one daemon handling all events, commads
- handle events differently by dongle type
- HTTP/REST based API - (somebody here published the code based on AMQP broker, maybe I will use part of his code)
- simple web app based on http://bottlepy.org/docs/dev/index.html (I hope it should work on openwrt)

Guys from CZ.NIC are working on plugins for Domoticz and Home Assistant. After the code will be released, to help them, could be a good idea :) Does it have some mobile app? ;)

Od samm

Dne 2015-08-02 17:44

"Putting all info to database looks like good idea, but every sensor have different events and different logic. Some of them have battery some don't, some have a tamper event, etc. It could be tricky to find reasonable model to handle it all. "

I was thinking about this. I was thinking between EAV model or flat table where all possible options are. Giving the fact that we have very limited set of hardware i decided to use flat table with all possible options. If some of them are not apply-able i will set NULL value. Code logic will be something like that:

receive_event() -> get_dev_type() -> process_event(type,event,serial) , so of course end function will know what kind of sensors device has. I never had experience with Domoticz and Home Assistant so it would be interesting to try when it will be ported.

Od B0iorix

Dne 2015-08-03 08:43

IMHO SQL is not the best way for storing information from gadgets, as they are too different. I think it would be better to use some kind of storage involving tree hiererchy. Yes, I mean LDAP. Another possibility could be mongodb.

Od samm

Dne 2015-08-03 09:19

ldap is kind of monster :) anyway i think that any db will fit, including dbd :) I decided to use sql also because of sqlite, to avoid any additional running daemons if possible.

Od Radomír Polách

Dne 2015-08-04 19:57

There are not many sensors, I am using single JSON.