A precastovat na float nestaci? Pouzivam grafanu v cloudu, kde by mela byt aktualni verze a funguje mi tohle (pouzivam teda flux misto influxql):

Skusal som to v influxql, tam to nejde. Flux vobec nepoznam.

Posted by: @dusanmsk

Aky datovy typ ma measurement ked sa to posiela cez UDP? Ja som totiz predvcerom upgradol grafanu a narazil som na problem (po dlhom badani), ze moj bridge tam uklada measurementy ako stringy. Coz nevadilo s grafana 4, ale kurva vadi s akoukolvek novsou grafanou, pretoze sice kresli diagramy, ale nezobrazuje hodnoty v hover tooltipe ani dole pod grafom. Trvalo mi 2 dni nez som vygooglil podobny problem a skutocne je to sposobene tym, ze su tie hodnoty ulozene ako stringy (a vysvetluje preco som so ziadnou nameranou hodnotou nebol schopny robit matematicke operacie).

Svoj bridge som fixol, ale ma to dalsi problem - v influxe nie je mozne kombinovat datovy typ u masurementu, takze sice posielam uz float, ale influx to zahodi, lebo ma na ten column nastaveny string. Treti den sa jebem s tym ako to napravit a musim povedat ze som na influx zhusta alergicky, taku sracku skurvenu som este snad ani nevidel. Resume - budem to riesit tak ze dropnem celu db (odzalohujem), nahodim 2 influxy a napisem kus kodu (uz len doladujem) co to bude z jedneho influxu citat a do druheho zapisovat ako float. A ta java liba k influxu to je lahodka uplne totalna. Vravim, 3 dni, jednoduchy task - skonvertuj/prehadz lopatou zo strany na stranu.

Measurementy poslané přes UDP se podle mě ukládají jako float. U jednoho measurementu jsem nejdřív posílal celá čísla, teprve po chvíli jsem začal posílat desetinná čísla a bez problémů. Matematika v nové grafaně funguje.

Jinak souhlas, to s těmi nezměnitelnými data typy je dost velký problém u influxu. Schema (tj. datové typy, tagy) se definuje automaticky jakmile do DB začneš ukládat data a pak už s ním nepohneš. Nezměníš datový typ, nepřejmenuješ tag, nesmažeš tag. Můžeš sice smazat všechny datapointy označené tagem, ale samotný tag ze schématu (indexu) nesmažeš...

Jsou tam i další věci, které mi na InfluxDB vadí ( https://github.com/influxdata/influxdb/issues/6878 ). Letmo jsem koukal na alternativy. TimescaleDB vypadá zajímavě, dokonce mají i skript na migraci z InfluxDB. Odradilo mě ale to, že TimescaleDB se krmí přes Telegraf, přitom ani nemají hotový output plugin pro Telegraf ( https://docs.timescale.com/latest/tutorials/telegraf-output-plugin ).

Takže..... pokud byste někdo našel funkční alternativu k InfluxDB, dejte vědět.

@budulinek pozri na https://www.postgresql.org/ ci by nevyhovovala. 
Kedysi to na nieco v praci pouzivali , ale priznam sa ze do DB sa nevyznam.

@smotek7 dík, ale hledám dedikovanou time series databázi. Seznam alternativ k InfluxDB třeba tady:

https://www.influxdata.com/time-series-database/

No ona timescale je vlastne postgres+timescale rozsirenie. Co som to letmo videl, prislo mi to ze to nie je schemaless a mne sa nechce vymyslat/vyrabat schemy, ja to doho chcem hrnut data. No a ked je v nich nejaka chyba, tak ich chcem (lahko) opravit. Kazdopadne primarna chyba bola hrnut do toho stringy z mojho mqtt->influx bridge, ale na svoju obhajobu poviem ze som netusil detaily influxu a grafana to zobrazovala, takze som to neriesil. Narazil som na to az po upgrade grafany (a zaroven prisiel na to, preco mi v influxe neslo spravit SELECT value * 1.1 FROM ...)

InfluxDB je komplexní řešení, tj. databáze plus služby poslouchající na HTTP(S) a UDP portech, kam můžeš snadno sypat data v jednoduchém formátu. Použití externích "krmičů" (Telegraf, Node Red, IoBroker, whatever) není nutné.

TimescaleDB je pouhá databáze. Použití krmičů (Telegraf, Kafka...) je nutné. AFAIK, tihle krmiči (Telegraf) se zároveň starají o automatické generování schématu. Takže Timescale + Telegraf je taky schemaless řešení (navíc s možností schema dodatečně upravovat). Problém je v tom, že Telegraf plugin pro Timescale (resp. pro postgresql) není hotový a vypadá to, že na něm ani nikdo nedělá...

BTW v diskuzích je zmiňovaný i Warp10. Vypadá to jako komplexní řešení (tj. databáze plus všechny věci kolem vč. služeb na https a UDP), které toho umí víc než influx, je schemaless. Ale zasekl jsem se hned v instalaci (java) a seru na to...

No mne influx vyhovoval az do momentu nez som nepotreboval skonvertovat tie stringy na floaty. Ocakaval by som, ze by mohlo existovat nieco ako:

select float("value") from measurement

ale bohuzial. Tak som ocakaval, ze proste exportnem celu db do niecoho, tam to zmenim a naimportujem naspat. Bohuzial. Influx vie exportovat do json a csv. Super, exportnem to do csv, odstranim uvodzovky okolo stringov a naimportujem naspat. No, alebo hovno, pretoze nevie importovat csv (!). Tak si hovorim ok, vie importovat klasicky line protokol, tak to exportnem do line protokolu, tam to fixnem a naimportujem naspat. No, akurat ze nevie exportovat do line protokolu (!!!). Ok, tak to teda kurva naprogramujem v groovy/jave, pouzijem influxdb-java-client libu. No, ale to co z tych selectov v tej libe lezie je jedna obrovska kopa zanorenych sraciek ktore som vobec nepochopil, takze u jedneho measurementu bolo value niekde v results[0][0][0].value a niekde v results[0][0].value. Ok tak s tym som sa vysporiadal nejak, ale ouha, u velkych measurementov dochadza pamat - chce to strankovanie. Aha, influx nema pouzitelne strankovanie. Hm, tak to ojebem "where time > X" a to X budem posuvat naposledne nacitany zaznam. Aha, ale ta liba mi nejak nezmyselne vracia neustale tu samu sadu dat bez ohladu na to where (s tymto som sa sral 3 hodiny, potom som to vzdal).

Po 3 dnoch laborovania som skoncil na tom, ze to exportujem do csv z commandline, nacitam do javy a zapisujem pomocou influxdb-java-client liby.

Sracka sracka sracka skurvena.

Ahoj
posledný mesiac sa sporadicky hrám s InfluxDB a snažím o zápis štatistík. Vyriešil som to tak, že pre každé meranie (measurement) som pod UDP Virtual Output-om pre každé čidlo vytvoril Virtual Output Command s príkazom v InfluxDB line formáte.

Pre analógové hodnoty (odškrtol som "Use as digital output") napr:

• Command for ON: "teplota_podlahy obyvacka=<v.2>"
• Command for ON: "teplota_vzduchu obyvacka=<v.2>"
• Command for ON: "teplota_podlahy poschodie=<v.2>"
• Command for ON: "teplota_vzduchu poschodie=<v.2>"

Pre digitálne hodnoty (zaškrtol som "Use as digital output") ako napríklad zapnutie vykurovania:

• Command for ON: "vykurovanie obyvacka=1" / Command for OFF: "vykurovanie obyvacka=0"
• Command for ON: "vykurovanie poschodie=1" / Command for OFF: "vykurovanie poschodie=0"

Problém s opakovaným zápisom nezmenenej hodnoty v pravidelných intervaloch, ktorý riešil @budulinek som vyriešil nastavením "Repetition Interval [s]" na hodnotu 600 (opakuje príkaz "Command for ON" pre zápis nezmenenej hodnoty kažých 10min)

Našiel som tam ešte parameter "First repetition [s]", ale po pravde netuším aký tam je medzi nimi rozdiel.

Prakticky mám potom v Grafane jednotlivé merania: teplota_podlahy, teplota_vzduchu, vlhkost, vykurovanie a pod nimi polia (field): obyvacka, poschodie, detska...

Prišlo mi, že by merania mali byť oddelené nie tagom (nechcem miešať hodnoty čidiel do jedného poľa) ale poľom. Tag by som použil ak by som chcel u konkétneho čidla "otagovať" množinu posielaných hodnot napríklad udalosťou, ktorá meranie sprevádzala (trebars pri meraní teploty podlahy zapnutím/vypnutím vykurovania).

@juraj

"Repetition Interval [s]" bohužel posílá opakovanou zprávu jenom v případě nenulové hodnoty. Proto tuhle funkci nepoužívám.

"First repetition [s]" dělá to, co má v názvu. Pokud máš "First repetition [s]" = 60 a "Repetition Interval [s]" = 10, tak se zpráva odešle po 60s a poté každých 10s.

Použití tagů na různá měření je podle mě OK, takto to má i InfluxDB a Grafana v návodech.

S tagy se dobře pracuje v Grafaně. Snadno je použiješ na filtrování a na pojmenovávání grafů. Čistá práce.

Ja som mal teraz grafanu 3 tyzdne mrtvu. Zbehlo sa u mna par okolnosti, ktore sposobili ze mi kazdu noc vypadol zber dat do influxu z dovodu vyssej zataze serveru kde to cele bezi. Tak som do toho zacal vrtat, pustil ./rebuild.sh a - prestalo to fungovat uplne. Node-lox-mqtt-gw hadzal nejake posrane nezmyselne exceptions a ja som absolutne nevedel, co s tym. Dokopal som sa k tomu az dnes s tym, ze to bud kurva rozchodim, alebo prekopem na posielanie udp priamo z loxone do influxu (coz by ale neriesilo situaciu ze mqtt pouzivam este na zigbee, takze vlastne nic).

No, tak som sa (zase, uz treti krat) ponoril do tajov sracky menom javascript a nodejs. Ten jazyk je mi uplne neznamy a fest neprehladny a nodejs tomu pridava event-based funkcionalne programovanie, ktore ale fakt naozaj naozaj naozaj z duse nenavidim. Chyba vyzerala nejak takto. Uplna chutovka pre cloveka uplne neznaleho nodejs sveta.

No, skratim to a pridam prosbu pre vsetkych vyvojarov na svete, ktori by toto mohli niekedy citat - nikdy nerobte rovnaku chybu a neuvadzajte zavislost na nejakej externej libe tak, ako to robil autor node-lox-mqtt-gateway:

"mqtt": ">=1.7.0"

Pretoze >=1.7.0 je napriklad aj 4.5.18 dopice. A tam uz asi tazko moze niekto ocakavat spatnu kompatibilitu. Potom niekto pusti rebuild po roku a cele sa to rozosere a nikto nebude tusit, preco.

Long story short - riesenim celeho problemu 3 tyzdnoveho vypadku bolo teda (zase) forknut node-lox-mqtt-gw a upravit zavislost ako:

"mqtt": "=1.*.*"  (*1)

No a zrazu to uz zase funguje.

*1 - nakoniec som zistil ze kompatibilna je este cela verzia 3, takze to skoncilo na 3.*.*.

@dusanmsk

Tu vyšší zátěž servru má na svědomí influx nebo něco jinýho? Měl jsem trochu vyšší CPU u influxu. Naštěstí mi to neshazovalo server, ale stejně jsem na to koukl a pomohlo

store-enabled = false

viz třeba

https://discourse.nodered.org/t/influxdb-on-a-raspberry-pi/742

Nesuviselo to s influxom. Stroj mava obcas v noci vysoky load (stretnu sa obcas verifikacie backupov z viacerych miest s btrfs scrub, takze je dost neresponzivny) a moj bridge medzi mqtt a influxom neprezije socket timeout a zasekne sa na nejakom deadlocku ktory som zatial neodhalil. Kedze proces neexitne a docker ho nerestartuje, tak nemam ziadne data v grafane :(.

K te verzi v package.json. Spravne reseni je imho "mqtt": "^1.7.0" - jakakoliv verze 1.x.x vyssi nez 1.7, eventualne "mqtt": "~1.7.0" - jakakoliv verze 1.7.x vyssi nez 1.7.0

Nebo vygenerovat a commitnout package-lock.json file. Ten zafixuje verze a v package.json muze byt cokoliv.