[Présentation] DomoRaptor

Salut à tous,

Après des années de tâtonnement, il est temps de vous présenter DomoRaptor mon assistant personnelle.

  • Historique:

A la base, c’était un simple automate programmable télémécanique (12E / 10S en code lader), le soft de programmation tournait sur Win XP (vous dire à combien de temps ca remonte) avec connexion série. le plus cool pour l’époque, mon oncle m’avait donné un module sim et donc je savais avoir les actio/info par sms. Il a tourné des années, jusqu’en 2018 … Son 1ier upgrade.

Puis arrive l’âge de la maturité. Fini le mode fête et je suis jamais chez moi. Entre temps, on évolue, j’achète la maison de mes parents en 2009 (pour x raison, et il vivent toujours chez moi) et donc mon endroit de vie ne change pas (le dernier étage avec 120m² au sol). Et la domotique? je n’y pense même pas, d’autre projet : Faire du grand garage un atelier voiture, finir les aménagements du jardin, etc. 2016 arrive, il est temps de penser à mon nid, en faire un appart T1. Et donc de repenser tout de A à Z. Et c’est la qu’arrive, le projet DomoRaptor.

2018, après des heures/jours/mois de recherche, d’achat diy (adrouino, Rasp, nodemcu, etc) et de test. La sélection est faite. Et oui, je choisis Jeedom. Il a l’avantage d’être open source tournant sur linux, en français, multi-protocole et une grande communauté ^^. Après l’achat dédié d’un pc et quelque mois de test, je choisis le plugin espeasy pour la gestion de l’éclairage, et des différents capteurs de la maison. Le but est d’avoir une solution simple que je peux présenter à des novices qui veulent domotiser leur maison sans passer par une solution clé en main hyper-cher. Donc, il faut que ca soit simple (sans trop de codage), efficace et fiable.

  • La config (2018):
    PC portable Asus ( I5 / 4G ram / HDD 500Go / max 60wh) : Ubuntu 18.4LTE faisant tourner jeedom et le serveur logitech
    Des NodeMcu esp8266 pour les différent capteurs (PIR / DHT / MQ2) et relais avec le FW espeasy R120 d’installé. L’avantage, installation par un soft windows en 4 lignes et gestion par page web.
    Jeedom :
    plugin espeasy / script / virtuel : pour les node
    plugin squeeze box / pionneer : gestion du son
    plugin pushbulet pour les notif
    (+ les autres de base comme mode / groupe / etc)

Les info sur récupérée avec le plugin espeasy
les actions sont envoyées avec un script et le retour d’état se fait par un virtuel (gain de réactivité par rapport au plugin)

Il tourne sous win 10 pro.
Jeedom / serveur logitech / serveur mosquitto (broker mqtt) tourne sur VM debian avec 4 cœurs / 4 go ram dédier (je pense à mettre la vm sur un ssd complet)
Il fait tourner des software pour le gestion de compte jeu : steam / android (bluestack) / bot en tous genre.
Et le plus important, il fait tourner un client vpn et le paramètre du bureau distant activer. Donc j’y ai accès de chez moi et de partout dans le monde.

  • Amélioration Jeedom depuis la V4
    le but est de fiabiliser au max donc l’utilisation de plugin officiel si possible.
    . remplacement du pushbulet par discordlink pour les notifs
    . Suppression du plugin espeasy et utilisation de jmqtt qui installe automatiquement le broker mosquitto. (a savoir que jeedom prépare un plugin officiel, je pense)
    . passage des nodemcu en mode « openhab mqtt » toujours avec le FW espeasy et inclusion auto des info via le plugin jmqtt. Avec la réintégration des nouvelles infos, une opération simple quand on regroupe/virtualise les commande action/info.
    . Refonte des scénarios de commande d’éclairage : Création de 2 scénarios générique, 1 de commande et l’autre de routage qui s’adapte facilement en fonction de la pièce (nbrs point éclairage) et des commandes voulu (jour/nuit ; auto/manu ; PIR ; 0-100% ; BP ; timer ; télérupteur).

  • En cours :
    . Retour d’état des nodemcu via dans règles et publication sur mqtt dans le fw espeasy pour permettre d’avoir un retour réel et non virtuel.
    . redondance (double commande) des actions avec les nodemcu. Comme le fw espeasy accepte les commande des relais via http et mqtt. prioriser mqtt mais si le broker est ko passer en http et faire des vérifications
    . évolution constante

Voili voilou, merci d’avoir lu jusqu’au bout, un peu fouilli, mais moi et mes 36 moi, c’est pas toujours évident lol :wink:
NicoRaptor

Citation : « Le monde est a vous. Au final, ce ne sont que des modifications de variable structurée en fonction d’une autre »

3 « J'aime »

Lo,

Belle présentation de ton univers autour de la domotique,
Je suis curieux de voir ta gestion via scénarios de tes lumières,

Bonne soirée,
Au plaisir,

Exemple avec l’éclairage de mon salon:


2 scénario et 1 virtuel (+ 1 virtuel pour un bp). En réalité, les 4 relais présent, c’est du virtuel d’un virtuel d’un script. Comme tout les relais/capteur de l’étage son centralisé dans l’objet « étage2 »

  • scénario commande (le plus long)

Commande l’éclairage en fonction de plusieurs tag : mode ; com ; lux ; temps ; boucle ; inc ; pause ; Rx ET des options auto/manu ; jour/nuit (par défaut mode inv en une boucle)

  • tag mode=« on » : allume en fonction du mode auto « jour/nuit » + un minuteur "tag(temps,60) et manu >« tag(lux,max) » sans timer // option tag(lux) inhibe la sélection jour/nuit ; tag(temps)
  • tag mode=« adapt » : adapte le lumière en fonction du jour/nuit sans modifier le timer
  • tag mode=« inv » : fonction télérupteur, utilise le mode « on » // option tag(lux) ; tag(temps)
  • tag mode=« off » : inhibe la partie « mode » du scénario pour passer des commandes direct avec le tag(com)
  • tag com : « jour » : allume le mode jour // « nuit » : allume le mode nuit // « max » : allume au max // « off » : éteint // « 0-100 » (par 10aine) : de 0 à 100%
  • tag Rx : c’est la partie commande Action // n’est pas une option
  • tag(boucle,1) : par défaut, il boucle sur le mode « inv » toute les 1sec, donc clignote (utilise le mode « on ») // option tag(lux) ; tag(temps) ; tag(pause,1)
  • tag(boucle,1) + tag inc=« on » : incrémentation de l’éclairage → avec boucle sur 7, allume successif de 0 à 70 // option tag(pause,1) ; tag(lux) pour le faire commence à une certaine étape
  • trigger(user) : a grader pour une fonction spécial

PS : il y a une extinction auto après 180min sur le mode « inactif »

Il se compose en 4 parties

Les modes

Les commandes

Les commandes action de l’équipement en lui même avec leur retour d’état

et la fin.

  • Le scénario routage (le plus complexe, si on veux jouer)

C’est juste un scénario d’enclenchement, c’est lui qui gère les options d’entrée/sortie. en test pour le moment avec des parties en fonction. J’aimerais y ajouter la possibilité de faire plusieurs choses avec le même BP (télérupteur + passage auto/manu + incrémenter)

Les déclencheurs

Utilisation des trigger pour savoir qui lance le scénario

Un conseil, attention à l’utilisation des Dans/A et pause/wait. Il y a des particularité à prendre en compte.

Commande Eclairage.json.txt (231,5 Ko)
scenario.txt (12,6 Ko)
Je ne vous partage pas le scénario routage. C’est surtout en fonction de la situation.

Par exemple, pour la cuisine, j’ai dupliqué la commande et routage et adapter pour 3 relais sans com nuit. Pour le hall, dupliqué et adapter pour 2 relais jour/nuit (soit en supprimant les partie en trop ou en les désactivant.

1 « J'aime »

Merci pour ce retour
Je vois que vous avez poussé votre gestion des lumières
Votre approche est très intéressante et complète

Au plaisir,
Bonne journée,

Avec plaisir. C’est beaucoup de lecture de doc et de compréhension des différents système possible. Puis des jours de réflexion avec une page blanche et prise de tête interne. Et enfin, l’illumination mdrrr.
Franchement avec les variables, les tags (variable unique au scénario), le plugin mode (variable « limité »), les virtuel, script et autre fonction ; il y a de quoi s’y perdre tout en ayant des possibilité infinie. C’est juste qu’il faut rester cohérant dans l’utilisation global avec un système homogène