Projet domotique -> choix des technos RasPi2

[destroyedlolo]

Salut,

Joli déterrage

'ai essayé plusieurs systèmes de base de données sur différents modèles de PI afin de stocker des données d'acquisition en temps réel et a chaque fois j'ai eus les même soucis : Lourdeur, lenteur et destruction à court terme des cartes SD.

Normal, une SD n'est absolument pas faite pour ça. Hormis les limites en écriture qui finissent par détruire les cartes, elles sont optimisées pour des accès séquentiels, pas aléatoire comme dans une BD ... donc ça RAMMMMMMEEEE !

Coté stockage des données, j'ai créé mon propre protocole et mon format de fichier. Je défini dans ma config la fréquence des enregistrements et la durée de vie de mes fichiers. Depuis que j'utilise cette méthode (près d'un an), je suis toujours avec la même carte SD

Oui, je le fais aussi pour la génération de données "statique" (en clair, où je n'applique que des critères fixes : le nom des fichiers permet alors de trouver facilement les données).

Apache, PHP, c'est bien, mais ce n'est pas fait pour ca.

Heu si, correctement optimisé, ca marche très bien : je l'ai fait dans une vie précédentes sur une station HP-712, et se gavait des données de tous les data center de ma boite (plusieurs centaines de serveurs) et je n'ai jamais eu de pb, même si la machine n'avait que très peu de RAM et de puissance de calcul par rapport à nos SBC, et je stoquais dans une base Postgres soit par des webservices Apache 2.0/PHP, soit par des scripts ... PHP.

Daemon d'acquisition en c++ (lib bcm2835 pour la rtc i2c et mon interface d'acquisition SPI) avec un port e/s UDP pour les commandes et un autre port udp en sortie pour broadcaster les données en temps réel.

Pourquoi ne pas utiliser MQTT ? C'est fait pour ça et du cout, t'as même plus a te soucier du bas niveau.

A+

Laurent

[Romuald]

...

[destroyedlolo]

Bhaaa ... déjà parce que je ne vois pas l'intérêt d'utiliser un éléphant attaché a un piquet pour écraser une mouche.

Ben un éléphant à l'allure de libellule alors : le MQTT vient de l'IOT et tourne depuis les microcontrôleurs dont les Arduino et les ESP, jusqu'aux gros serveurs de Faceproot.
Mais face à un broadcast UDP, il permet (si tu le veux), d'ajouter du QoS, la valeur par défaut pour des clients morts. Mais comme le broadcast, le nombres de consommateurs n'influent pas sur la charge réseau.

Je précise qu'habituellement je fais plus ce genre de chose en assembleur, donc tu sais le bas niveau en c++ c'est très subjectif pour moi ...

Ben ayant lu W10, j'ai eu peur
Ayant débuté mes bidouilles sur des machines 8 bits tournant à 500khz avec 2 ou 3 ko de RAM dans le meilleurs cas et où "l'UART" était géré en soft en comptant les cycles CPU, l'optimisation est quelques choses d'important pour moi.
C'est pourquoi mon systèmes à base de webservice tournait très bien sur la station HP (et il restait des ressources) alors que les systèmes soit-disant pro équivalent à la HP-OpenView se sentait à l'étroit sur de gros serveur HP-PA multiproc.

Pour ma Domotique, j'ai pensé aussi faire du broadcast UDP ... sauf que ça m’obligeait à redevelopper une stack sur chaque type d'objets. Et c'est là que j'ai découvert le MQTT qui était l'esperanto pour tous ces objets, le tout étant largement plus leger que de faire du REST ou sa version light, le Coat.

Perso, ca me va bien comme ca.

C'est bien là le principale

[Romuald]

...

[destroyedlolo]

Bha t'as bien de la chance d'avoir eus a débuter sur des machines parce que perso, quand j'ai commencé, on avait juste les processeurs et les datasheet en anglais et fallait se demerder avec ca. Si tu voulais de la mémoire, bha fallait la souder et se palucher l'adressage. C'était à une époque ou il ni avait pas d'internet pour se documenter. À la place on avait des trucs énormes en papier .... des livres je crois qu'on appelait ca

Quand t'as 12 ou 13 ans, t'as pas accès à ce genre de ressources (et encore moins les moyens de me payer des composants qui coutaient un bras par rapport à mon "argent de poche"). Donc j'ai bidouillé avec ce que j'avais, à savoir mes Pocket Sharp. Le seule chose que j'ai réussi à récupérer a été les mnémoniques assembleurs d'une revue (pas d'internet à l'époque). Mais desassembler leur ROM, leur ajouter un joystick en dérivant le port K7 ou RS-232, faire de l'I2C en comptant les cycles et autres joyeusetés sont très formateur
Je n'ai eu accès aux microcontroleur qu'au bac.

Pour ma Domotique, j'ai pensé aussi faire du broadcast UDP ... sauf que ça m’obligeait à redevelopper une stack sur chaque type d'objets.

Pas nécessairement. Perso, je balance la config des capteurs une seule fois a la connexion du client ce qui me permet ensuite de ne transférer que les données.

???? on ne parle pas du tout de la même chose. Ce que je disais c'est que sur les objets les plus simples (genre les micro-controleur ou les ESP), ou sur les différents clients haut niveau (applis Android, scripts Conky pour Linux, appli en C pour mon dashboard, client Web), ca m'obligeait à chaque fois à développer la couche transport.
MQTT existant sur tout ces objets, je n'avais pas à le faire et en plus, je n'ai pas à me soucier du médium utilisé. Sans compter comme je le disais, le QoS qu'il fournit est très pratiques pour les connexions non stables.

...
Ben ayant lu W10, j'ai eu peur

C'est typiquement pour ce genre de réflexion que j'ai jamais pus encadrer les linuxiens . N'en déplaise, mais pour l'instant, avec le pi j'obtient de meilleurs résultats sous win10IOT que sous raspbian , comme quoi . Perso, je ne suis pas sectaire. Je m'accommode aussi bien de l'un que de l'autre.

Hé bé Y'avais un jolis smiley.
Mais si ton Raspbian n'a pas les perfs attendu, y'a peut-être des optimisations a faire.
Pour la gueguerre m$ vs Unix, oui, je revendique mon côté anti-m$ primaire que mon expérience professionnelle m'a conduit à être : je n'ai strictement aucune confiance dans leurs produits et encore moins dans la pérénité de w10 IoT ...
Mais bon, autre chose à faire que rentrer dans ce genre de débat

[Romuald]

...

[destroyedlolo]

Salut,

Sans remettre en cause quoi que ce soit, après tout, chacun fait ses choix et l’important reste quand même de s’amuser, mais il y a quand même quelques inexactitudes dans

Même si c'est relativement léger, le poids d'un échange MQTT est énorme comparé a un tableau json de quelques octects que l'on glisses dans un socket

D’après les spec,

A small transport overhead (the fixed-length header is just 2 bytes), and protocol exchanges minimised to reduce network traffic

Ce qui est parfaitement négligeable par rapport à la surcharge dû au Json lui-même (formatage, le fait que les données soient en format text). Auquel s’ajoutent bien sur la connexion initiale, mais qui comme son nom l’indique, n’a lieu qu’une fois.
De plus, les trames échangées sur un réseau Ethernet seront au minimum de 64 octets (les loopback ne devraient pas avoir ce seuil minimum, enfin, je n’ai jamais vérifié).

Je n’ai jamais fait des tests de perfs sur Mosquitto mais faire du broadcast direct est évidement plus rapide que n’importe quelle solution utilisant un intermédiaire. Je n’en ai fait que sur de grosses solutions professionnelles, en l’occurrence Universal Messaging de webMethods mais les problématiques ne sont pas les mêmes (entre autre, parce que fait en Java avec tous ce que cela implique en terme de lourdeur et de tuning).

[olivierd]

Bon
je suppose que ton projet est abouti...
tu peux nous faire un retour?
as-tu regardé ce que proposait node red?

olivier

[vr34]

Bonjour,
Pour répondre au titre, il y a aussi la solution Jeedom (ou Domoticz). Jeedom fonctionne sur RPi2
Elle est un peu plus chère (dongle zwave, rfxcom, périphériques) mais très stable, largement documentée (manuels, gros forum, tout en français) et peut éviter de "mettre les mains dans le cambouis" (GPIO, soudures, ...)