Multi-platform Docker image for CCU-Historian.
Home Page: https://hub.docker.com/r/xjokay/ccu-historian
License: MIT License
Welcome to my GitHub profile.
"Perfection is attained not when there is nothing more to add,
but when there is nothing more to remove."
Antoine de Saint Exupéry
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
![renovate[bot] avatar](https://avatars.githubusercontent.com/in/2740?v=4 "renovate[bot]")
This issue provides visibility into Renovate updates and their statuses. Learn more
This repository currently has no open or pending branches.
der ccu-Historian macht mir immer die Diagramm-Daten auf dem USB-Stick der CCU (folder usb0/measurement/ ) unslesbar. Die Daten sind weiterhin auf dem Stick, aber die CCU meldet nach der Installation von ccu-Historian sowohl unter der Option Status/Bedienung, Diagramme wie auch unter Einstellungen Diagramme, dass kein USB Stick vorhanden sei.
Ich kann die Daten wieder nutzen, indem ich sie auf ein anderes Medium kopiere, den Stick neu formattiere (FAT32 oder NTFS) und dann wieder auf den Stick kopiere. Das Kopieren muss ich aber per SFTP Zugriff auf den USB Stick im Raspi (CCU ist raspberrymatic, latest version) kopiere. Wenn ich diese auf den USB Stick im Mac (oder auch am Win10 PC) kopiere scheint es die CCU auch nicht zu finden.
To Reproduce
Dieser Fehler tritt sowohl auf, wenn ich den ccu-Historian als addon in der CCU installiere (finde ich die beste Lösung - eigentlich) oder wenn ich diesen auf der Synology in Docker installiere.
Steps to reproduce the behavior:
Environment (please complete the following information):
Anm: ich glaube, ich hätte mal das gleiche Problem beobachtet nach einem Zugriff des iobroker auf die CCU, bin aber nicht sicher, ob dies wegen iobroker war oder wegen ccu-Historian. Konnte dies mit iobroker nicht mehr reproduzieren, habe aber mit iobroker auch das Problem, dass das rfd Modull keinen Zugriff erhält (das CuxD Modul findet die Daten hingegen) Dies ist wohl ein ganz anderes Problem, sei hier aber mal erwähnt, ev hat es doch einen Zusammenhang, Zugriffsproblem etc. ...
Die V2.3.1 wurde auf Grund eines Fehlers zurückgezogen.
Siehe mdzio/ccu-historian#203
https://github.com/mdzio/ccu-historian/releases/tag/2.3.1
https://homematic-forum.de/forum/viewtopic.php?f=38&t=54635
Describe the bug
I enter NAT (default) with all ports and after the installation I get Bridge with 10.0.3.2
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Environment (please complete the following information):
Command used to run the container
Docker compose file (with passwords redacted)
services:
image: ...Additional context
Add any other context about the problem here.
Describe the bug
Hallo, bin nicht sicher ob dies ein bug ist oder einfach eine Einstellungssache: ich habe realisiert, dass die Daten im Historian (auf Syno 718, docker) um 1h verschoben sind (i.e. es wird 16h anstelle von 17h angezeigt, etc.)
Das NAS und die Raspberrymatic (seprates Raspi Pi3) zeigen beide die gleiche, aktuelle Systemzeit an
A clear and concise description of what the bug is.
To Reproduce
Zeit in ccu-historian Grafiken um 1h verschoben (zu früh)
Steps to reproduce the behavior:
ccu-histirian grafiken im Webbrowser wie auch auf iOS in der app HistClient
Expected behavior
A clear and concise description of what you expected to happen.
Environment (please complete the following information):
Command used to run the container
Docker compose file (with passwords redacted)
services:
image: ...Additional context
Add any other context about the problem here.
The documentation should be extended:
By setting the environment variable CONFIG_KEEP_MONTHS, maintenance is performed before the CCU-Historian is actually started. One after the other the CCU-Historian is called with the options -clean, -recalc and -compact.
See also: Comment on CCU-Historian Issue
Hallo,
ich habe noch nicht soviel erfahrung, deshalb bitte nachsicht falls ich was falsch mache.
ich habe die 4 Enviroment Variablen hinzugefügt und die Zwei Volumes gebunden.
im Log bekomme ich:
/usr/local/bin/docker-entrypoint.sh: 8: /usr/local/bin/docker-entrypoint.sh: [[: not found 2019-06-24 17:31:15|INFO |CCU-Historian V2.1.0 2019-06-24 17:31:16|INFO |(C)MDZ ([email protected]) 2019-06-24 17:31:16|SEVERE |Exception: Can't access configuration file /opt/ccu-historian/config/ccu-historian.config 2019-06-24 17:31:16|SEVERE |Detail: java.lang.Exception: Can't access configuration file /opt/ccu-historian/config/ccu-historian.config at mdz.ccuhistorian.Configuration.isFileModified(Configuration.groovy:100) at mdz.ccuhistorian.Main$_run_closure3.doCall(Main.groovy:73) at mdz.ccuhistorian.Main$_run_closure3.call(Main.groovy) at mdz.Exceptions.lambda$0(Exceptions.java:84) at mdz.Exceptions.catchToLog(Exceptions.java:74) at mdz.Exceptions.catchToLog(Exceptions.java:84) at mdz.ccuhistorian.Main.run(Main.groovy:72) at mdz.ccuhistorian.Main.main(Main.groovy:47)
Wenn ich das Config File manuell ablege
bekomme ich diesen log
2019-06-24 17:38:05|INFO |Connecting to 192.168.0.109:8701 2019-06-24 17:38:05|INFO |Starting historian 2019-06-24 17:38:05|INFO |Starting web server 2019-06-24 17:38:06|INFO |Web server port: 80 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.43252.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.35086.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.35085.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.35087.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.950.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.6625.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.6732.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.6718.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.32546.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.45813.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.45815.VALUE 2019-06-24 17:38:07|INFO |Historian: Creating data point SysVar.45814.VALUE
aber das database Verzeichnis bleibt leer und beim nächsten restart beginnt er eine neue Datenbank
This seems to be a problem with your environment and not the Docker container itself.
The Docker host / your own setup defines the used network and not the container.
Originally posted by @jokay in https://github.com/jokay/docker-ccu-
historian/issues/357#issuecomment-1902767039
Hello Jokay,
it works so many years very good, but now it don't save the IPs.
Do you have any idea whats wrong with my Network ?
I have three other dockers, they work fine
Greetings
Holger
Hello,
first this is not a bug but a question.
I am using QNAP QTS 5.0 with Container Station 2.6.1 whitch is a Docker system.
At the "store" of container station I found the docker image for historian, build by jokay.
I tried many path variants to store the automatic backup but there is no error from historian or docker. At the command line every day it is simply shown
2022-08-27 00:59:58|INFO |Creating backup of database to file HistorianBackup_2022-08-27.zip
But nowhere on the whole storage I could find this or the files.
So the first question is, where could I find the "successfully" created file? Or is the message from historian not true?
Second question is: How to store the automatic backups outside the docker system. Just on a simple share. I know, that is not in the scope of historian itself but maybe I could find tips here.
I cannot provide docker-compose.yaml and neither the docker run command.
Please tell me how to get them from my environment.
So therefore I would need more specific information how to get to this information.
Actually I think its all default how I gets out of the image, because I did not change anything but the ccu-historian.config whitch is attached.
OS: QNAP QTS 5.0
Docker version:
Client: Version: 20.10.17-qnap1 API version: 1.41 Go version: go1.17.11 Git commit: 0474f29 Built: Tue Jun 14 10:41:04 2022 OS/Arch: linux/amd64 Context: default Experimental: true Server: Docker Engine - Community Engine: Version: 20.10.17-qnap1 API version: 1.41 (minimum version 1.12) Go version: go1.17.11 Git commit: 571a584 Built: Tue Jun 14 03:04:25 2022 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.6.6 GitCommit: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1 runc: Version: 1.1.2 GitCommit: v1.1.2-0-ga916309f docker-init: Version: 0.19.0 GitCommit: de40ad0
I was told docker is that much easy, but it seems to bit a little bit difficult just to find a single file.
So I need more help to get more information more like "step by step" manuals.
But I want to thank you @jokay. The container and the historian is working fine and fast, so you did a good job.
If the backup is running it is perfect :)
Best regards,
flow4it
There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.
File: .github/renovate.json
Error type: The renovate configuration file contains some invalid settings
Message: Invalid schedule: 'Invalid schedule: Failed to parse "0 0 * * * *"'
Hallo zusammen.
Ich hänge jetzt schon seit Tagen an einem Problem und finde keine Lösung.
Vielleicht hat hier jemand eine Idee was die Ursache dafür sein kann.
Ich habe ein Upgrade von UNRAID 6.9.2 auf 6.10.3 gemacht (Docker 20.10.5 -> 20.10.14).
Danach habe ich festgestellt, dass der Container xjokay/ccu-historian:3.3.1 zwar gestartet werden kann, aber dann in der Startsequenz hängen bleibt.
Um das Problem zu beheben habe ich wieder ein Downgrade zurück auf UNRAID 6.9.2 gemacht.
Das Problem ist jetzt aber, dass der Container jetzt auch damit nicht mehr richtig startet.
2023-07-19 20:06:41|INFO |xjokay/ccu-historian 3.3.1
2023-07-19 20:06:41|INFO |Starting CCU-Historian using the following config:
|---
|database.dir='/database'
|database.webAllowOthers=true
|devices.device1.address='192.168.1.200'
|devices.device1.type=CCU3
|devices.device1.plugin1.type=CUXD
|devices.historianAddress='192.168.1.100'
|webServer.historianAddress='192.168.1.100'
|webServer.showLastValue=true
|---
2023-07-19 20:06:42|INFO |CCU-Historian V3.3.1
2023-07-19 20:06:42|INFO |(C)MDZ ([email protected])
2023-07-19 20:06:42|INFO |Starting base services
2023-07-19 20:06:42|INFO |Connecting to database
2023-07-19 20:06:43|INFO |Starting database web server
2023-07-19 20:06:43|INFO |Setting up device 1
2023-07-19 20:06:43|INFO |Creating HM script client for http://192.168.1.200:8181/tclrega.exe
2023-07-19 20:06:43|INFO |Setting up plug-in 1
2023-07-19 20:06:43|INFO |Configured following interfaces: BidCos-RF, HmIP-RF, SysVar, CUxD
2023-07-19 20:06:43|INFO |Starting interfaces
2023-07-19 20:06:43|INFO |Starting BIN-RPC server on port 2099
2023-07-19 20:06:43|INFO |Starting XML-RPC server on port 2098
Danach geht es nicht mehr weiter, auch Stunden später tut sich nichts.
Wenn ich den LogLevel auf ALL stelle sehe ich, dass die RPC-Schnittstelle einwandfrei mit der CCU3 kommuniziert.
Aber der Webserver für die UI startet nicht.
Woran kann das liegen?
first of all, backup is working now for me
I had to replace within the instruction line in the configuration "/db" by "/database"
Misleading for me were the differences in names. On my docker installation, the database is stored in directory /docker/historian/db, while in ccu-historian.config it is named /database (database.dir='/database').
Logging
in directory docker/historian/db/log is visible for me now with corresponding adjustments in the config file
logSystem.fileName='/database/log/ccu-historian-%g.log' while the directory on the server is named /docker/historian/db/log
Syntax for external storage
In some cases it might be helpful to have the syntax available, in case a different server for storage is preferred.
Thanks
Paul
Hi all
ich habe das docker image xjokay/ccu-historian im docker auf synology sowie in einem völlig unabhängig davon aufgesetzten Raspberry PI 3B (1G Ram, 32GB SD Card, mit docker, portainer, keine weiteren containers) aufgesetzt. In beiden Fällen war zwar die Installation des image erfolgreich, ohne Fehlermeldungen, aber der ccu-Historian stoppte am Ende des Startprozesses, d.h. nach jeweils 30'-60', um dann im docker der synology sofort den Startprozess automatisch wieder zu beginnen (auf dem Raspi musste ich manuell re-starten), bis ich diesen Zyklus manuell stoppe. Die Beobachtung ist wiederholbar mit verschiedensten Versuchen.
Ich habe die Folders gem. Instruktionen im portainer gemappt, die ports mal manuell 1 zu 1, mal auch automatisch im portainer (dann im host random-ports) gemappt.
Ich fand bisher noch keinen Grund für den stop, woran könnte das liegen? laufen die anderen instanzen mit dem neuesten image?
Docker Image für xjokay/ccu-historian: latest 30.10.2022
Protokoll-FIle:
xjokay-ccu-historian1.csv
anscheinend fehlen environment variablen?
Run application as non-root.
Add additional environment variables to be able to set the used group-id and user-id.
GID=999
UID=999Der Zugriff auf die Datenbankoberfläche (Werkzeuge → Datenbank) funktioniert nur von einem anderen Gerät aus, wenn die Option database.webAllowOthers=true gesetzt ist. Vielleicht sollte sie mit in die Standardkonfiguration aufgenommen werden.
Siehe auch Foren-Beitrag.
Hi,
I wanted to upgrade from 2.8.3 to 3.0.1 and as I was trying to start up my docker-compse.yml file, I get the following issue:
Starting ccu-historian_app_1 ... done
Attaching to ccu-historian_app_1
app_1 | standard_init_linux.go:228: exec user process caused: exec format error
ccu-historian_app_1 exited with code 1
I was able to upgrade to 2.9.0 without issues.
I use docker-ccu-historian on a Raspberry Pi 4 with Ubuntu 21.10.
Linux pyfhem1 5.13.0-1024-raspi #26-Ubuntu SMP PREEMPT Fri Mar 25 10:54:36 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
more /etc/issue
Ubuntu 21.10 \n \l
Thank you,
Regards,
Jochen
The following new environment variables should be supported:
devices.device1.username='my-ccu3-username'
devices.device1.password='my-ccu3-password'Related mdzio/ccu-historian#215.
Hallo,
ich betreibe den CCU-Historian aktuell noch als Addon auf der Raspberrymatic, möchte diesen jedoch gerne auf einen separaten Raspi in einem Docker-Container umziehen.
Meine bisherigen Kenntnisse mit Docker sind, sagen wir mal, sehr überschaubar. Aber jeder hat mal klein angefangen :)
Am liebsten hätte ich den Historian in einer MariaDB-Datenbank, diese läuft auch schon auf dem Raspi.
ich habe nach Anleitung https://hub.docker.com/r/xjokay/ccu-historian den Historian in Docker installiert, was soweit auch geklappt hat. Das Webinterface ist erreichbar unter :8082
Möchte ich mich hier mit einer Generic H2 Embedded Datenbank verbinden, kommt als Fehlermeldung:
Database "/root/test" not found, either pre-create it or allow remote database creation (not recommended in secure environments) [90149-214] 90149/90149 (Hilfe)
Nehme ich z.B. MariaDB, kommt als Fehler ein fehlender Treiber (ich habe irgendwo gelesen, das man dazu den Treiber beim Start einbinden müsste?).
Als Addon auf der CCU war die Generic H2 Embedded sofort da, wenn ich mich recht entsinne.
Habe ich was falsch gemacht oder wo liegt der Fehler?
Hier meine Konfiguration zum Start (ich musste Port 80 durch 81 ersetzen, da auf Port 80 schon ein lighthttpd läuft):
docker run -d
-v $PWD/data/database:/database
-v $PWD/data/config:/opt/ccu-historian/config
-p 81:81
-p 2098:2098
-p 2099:2099
-p 8082:8082
-e TZ=Europe/Zurich
-e CONFIG_CCU_TYPE=CCU3
-e CONFIG_CCU_IP=192.168.2.12
-e CONFIG_HOST_IP=192.168.1.7
-e CONFIG_HOST_BINRPCPORT=2099
-e CONFIG_HOST_XMLRPCPORT=2098
-e CONFIG_CCU_PLUGIN1_TYPE=CUXD
-e CONFIG_KEEP_MONTHS=12
docker.io/xjokay/ccu-historian:latest
PS: Cool wäre, wenn man dem Docker-Container eine andere IP-Adresse zuweisen könnte, dann wäre auch der schon belegte Port 80 kein Problem. Ich habe grob gelesen, dass das mit Docker wohl grundsätzlich geht, aber mich bisher nicht näher damit beschäftigt. Gibts da eine einfache Anleitung für? Danke!
Hello,
first I have to say this work is great. Thanks a lot for this!
After changing the configuration of many data points in ccu-historian into the docker container I want to recalc and compact the database.
In the past - without docker container - i have done this manually into a terminal session, so I know this process.
When I stop the container it is not possible to get access to start ccu-historian with start paramters.
Could you give a short explanation the process for users (I'm not an expert...) how to do this?
Many thanks!
Currently the graphs are not working.
See openjdk issue docker-library/openjdk#256.
is there a possibility to configure automatic backups like
database.backup='/path/directory/ccu-historian/backup/%Y-%M-%D-Hist-Backup'
similar to stand-alone installations ?``
Moin,
Danke für das Klasse Docker-Teil! Läuft auch auf Anhieb, allerdings habe ich es nicht hinbekommen, auf die Datenbank auf Port 5435 zuzugreifen. Kenne mich mit Docker noch nicht so gut aus, aber es sieht so aus, dass dieser Port auch gar nicht EXPOSED ist.
Wäre das möglich, das zu ergänzen? Habe nämlich schon Grafana in einem anderen Container laufen und möchte die Daten von CCU Historian gerne anzuapfen :-)
Vielen Dank,
MoosHam
Hello,
first of all, thank you for your work.
I recently was using your docker container on a Raspberry Pi 4 with 4 GB of RAM.
After some time I was unable to establish a ssh connect to the Pi anymore.
I needed to disconnect power of the Pi. After that I was able to establish a new ssh session to the PI.
I found out in the kern.log that there were some Out of Memory situations with the java process of ccu-historian.
Currently I can see that the RAM usage is increasing.
79923 root 21.5 java -jar /opt/ccu-historian/ccu-historian.jar -config /opt/ccu-historian/config/ccu-historian.config
Please add a possiblity to configure the Java Heap Size Memory (-Xmx) exposed in the docker-compose file.
Thank you.
Regards,
Jochen
Describe the bug
I'm using UNRAID with docker xjokay/ccu-historian. When trying to stop the container via UI, the UI shows a running cycle for approx. 30 sec and then an error message appear: "Fehler bei der Ausführung". Then a forced shutdown of the container is done.
Root cause:
A shutdown of the docker container doesn't signal the java process to shutdown, it only signals the parent shell process. Shutdown hangs until time limit is reached and remaining processes are killed.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A graceful shutdown of docker container to prevent any damages to the database.
Solution proposal
Add the command "exec" before every java command in entrypoint.sh.
This forces the java process to get PID 1.
Before:
$ ps -elf
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S 99 1 0 0 80 0 - 1745 - 19:22 ? 00:00:00 /bin/bash /usr/local/bin/entrypoint.sh
0 S 99 9 1 3 80 0 - 1555107 - 19:22 ? 00:01:07 java -jar /opt/ccu-historian/ccu-historian.jar -config /opt/c...
4 S 99 550 0 0 80 0 - 654 - 19:59 pts/0 00:00:00 sh
0 R 99 556 550 0 80 0 - 2224 - 19:59 pts/0 00:00:00 ps -elf
$
After:
$ ps -elf
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S 99 1 0 99 80 0 - 1727874 - 00:31 ? 00:00:08 java -jar /opt/ccu-historian/ccu-historian.jar -config /opt/c...
4 S 99 64 0 0 80 0 - 654 - 00:31 pts/0 00:00:00 sh
0 R 99 75 64 0 80 0 - 2224 - 00:32 pts/0 00:00:00 ps -elf
$
Environment (please complete the following information):
Additional context
When Docker attempts to stop a container, it will send the specified signal to PID 1, the process that Docker starts. Docker will completely ignore any other process running within this container. So that means when we issue a docker stop, the Docker daemon will send a SIGTERM signal to the docker-entrypoint.sh process, not to the running service.
Is it possible to add the following two environment variables to make the database smaller?
CONFIG_COMPACT_CRON
Specifies in the normal cronjob format how often the compression should be executed (for example "* * 1 * *")
If there is nothing in it, there is no compression.
CONFIG_COMPACT_KEEP_MONTH
Number of months you want to keep data (for example "12")
Then at the time defined in the variable CONFIG_COMPACT_CRON a script has to be executed which does the following one after the other.
This would be great.
I hav done the update from v2.8.1 to 2.8.3. The new version is running and show the version# top right.
The value of the container environment variable 'VERSION' was not set to the new number.
This is shown in the ccu-historian logfile, the container-overview-screen on DSM and of course the setting page for the environment variables.
So I had to set it manually there.
Because I do not have many expierience with containers my question: Is that correct?
From other containers (e.g. pihole) I know that a new version automaticaly set the correct version number in corrosponding environment variables.
The images should be build for multi-platform using Docker Buildx.
Hi,
running this container on docker, it stops after a few seconds with the following error in the log:
standard_init_linux.go:219: exec user process caused: exec format error
Running it with the unchanged run parameters, except for the IPs.
Any idea what this could be?
Thanks and regards!
Hilmar
If you are seeing this message ...
"Die bestehende Datenbank muss für CCU-Historian V3 migriert werden! Datenpunkte können nicht aufgezeichnet werden!"
... and you didn't export your data via Web-UI before updating to 3.0.x (this may happen if you are using the tag :latest), downgrade to 2.9.0 and follow the instructions on the CCU-Historian 3.0.2 release notes.
docker.io/xjokay/ccu-historian:2.9.0history.mv.dbdocker.io/xjokay/ccu-historian:3.0.2 or docker.io/xjokay/ccu-historian:latestRelates mdzio/ccu-historian#310.
Hallo
Vielen Dank für das Historian Docker Image und vor allem, dass Du es auch pflegst!
Ich habe bisher CCU-Historian direkt (ohne Docker) auf einem QNAP NAS betrieben. Jetzt habe ich versucht es umzustellen auf Container Station mit Deinem Docker Image. Die alte Historian Softfware lief direkt auf einem Share auf dem NAS, die DB befindet sich im Unterordner Data. Natürlich möchte ich die bestehende DB weiter verwenden. Deswegen habe ich die Volumes /database und /opt/ccu-historian/config auf diesen Share konfiguriert. Die Config wird auch tatsächlich von diesem Share geladen. Aber bei der DB klappt das leider nicht. Das Docker Image erstellt immer wieder eine neue leere DB in dem Container Folder ohne den Share auf den /database zeigt zu beachten. Was mache ich falsch?
Sorry, ist wohl kein Feature Request, aber wusste nicht wo sonst posten...
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.