Lazer

http://192.168.1.1/api/scenes/13 Requête PUT : {"id":13,"name":"Shutdown","roomID":0,"enabled":false,"autostart":false,"protectedByPIN":false,"killable":true,"visible":true,"isLua":true,"lua":"--[[\n%% properties\n%% events\n%% globals\n--]]\n\nfibaro:debug(\"Going to shutdown...\")\nHomeCenter.SystemService.shutdown()\nfibaro:debug(\"Shutdown launched !\")\n","html":"<span id=\"hiddenFields\">\n<input value il faut donc que tu récupères l'API complet de ta scène, tu changes juste le paramètre "enabled":false, puis tu réinjectes l'ensemble en PUT

Alors làoui c'est possible, parce que l'interface Web utilise l'API pour modifier une scène. Mais faut trouver la syntaxe, et ça va être une requête HTTP de type POST, donc il faut un plugin spécial ou utiliser curl en ligne de commande.

euh, j'ai peut être pas tout compris ? Sinon dans la ligne du config GEA du watchdog, tu as un paramètre restart = true que tu peux changer

désactive la scène watchdog, tout simplement non ?

Jojo ton 503 après une exclusion ressemble au 503 après la suppression du plugin Netatmo mentionné sur le forum officiel. Surement le même bug. Essaye de les contacter en urgence, dès fois qu'lis puissent te dépanner ...

Moi j'utilise http://www.meteo-paris.com/ car le site est expertisé manuellement, mais ceci est valable uniquement pour la région parisienne. L'avantage c'est qu'ils font clairement la différence entre Paris, la banlieue, l'est/l'ouest/etc. Permet même de faire un barbecue dehors et de finir sans crainte avant l'arrivée de l'orage (uniquement if annee ~= 2016 .... else barbecue = nil) Pas de récupération des données non plus pour un usage domotique, làc'est juste pour avec des prévisions fiables.

YR : Grand Soleil, 20°C HC2 : idem en tout point à YR Réel (je suis devant la baie vitrée du salon...) : ciel totalement gris, luminosité faible, 19,5°C Pour une fois, il n'y a que 0,5°C de différence sur la température, mais pour le reste c'est tout faux Donc ce n'est pas la HC2 la fautive, mais le service YR. Je ne sais pas d'où ils obtiennent leurs données, mais ils ne doivent pas avoir de station de mesure à proximité de Paris. Quant à Yahoo, je pense qu'ils devaient acheter les données à Meteo France, car je suis entre 2 stations connues (Paris Montsouris et Le Bourget)

@Moicphil : oui mais bon, là on ne demande pas des prévisions météo, mais juste le relevé des mesures, pas difficile quand même. Pour le coup, Yahoo étant quand même très très précis, à 15 minutes près, je pouvais comparer le passage d'une averse sur l'impact de la chute de température. @Quikdav : oui en effet, une des nombreuses demandes parmi tant d'autres

Puisqu'on parle météo, j'en profite pour faire un retour d'expérience sur le nouveau service Météo retenu par Fibaro depuis cette version : yr.no => C'est inexploitable C'est bien simple, ça fait maintenant 8 jours qu'on n'a pas vu le soleil à Paris (et je crois que les medias ont assez parlé des inondations....), avec des températures très largement en dessous des normales saisonnières, je n'avais encore jamais eu besoin de remettre en marche le chauffage en juin, maintenant c'est fait :/ Je précise que ma HC2 est parfaitement localisée, aussi bien au niveau de la ville que des coordonnées GPS. D'ailleurs les heures de coucher/lever du soleil sont parfaitement calculées. Malgré cela, la HC2 m'annonce un grand soleil alors que nous sommes sous la pluie, des température l'après-midi jusqu'à 4°C supérieures à celle relevées dans mon jardin, ce qui implique une différence de température moyenne sur la journée allant jusqu'à 2°C certains jours (vérifié avec Domocharts). Idem, de très grosses différences sur l'humidité (en moyenne 30% en moins que le réel), et sur la force du vent (pareil, beaucoup moins de vent que le réel) C'est un peu comme si YR était toujours optimiste, il faut beau, sec, et sans vent. Bref, la météo YR sur la HC2 est devenue totalement inutilisable dans des scénarios :( :(

Ah oui, un retour sur la station Qubino, elle m'intéresse celle là Justement pour son absence de Cloud.

@Steven, je ne pense pas que le plugin Netatmo soit plus particulièrement responsable des 503 que n'importe quel autre VD/Scène/Plugin. Sur ma box de prod, j'ai le plugin Netatmo, et les 503 sont rares. Sur ma box de test, je n'ai pas le plugin Netatmo, j'ai 1 seul module Z-Wave, et de rares scènes/VD (qui ne font rien, main loop vide), et pourtant j'ai eu un 503 sans y toucher. Toujours ces plantages aléatoires....

Bon, ce soir je me connecte sur ma box de test pour tester un truc : je la trouve en mode 503 Je ne sais pas depuis combien de temps vu que je n'ai pas remis le watchdog dessus Evidemment le bouton "Restart Services" ne fonctionne pas, on se demande à quoi il sert Heureusement qu'on a le /services/finishUpgradeAfterError.php qui est efficace

ça dépend, y'a des femmes à barbe... Grillé

@sebcbien les imprimantes 3D c'est trop barbu pour moi, ça ne me tente pas (encore... )

MySensor, c'est pour les barbus / mauvaise foi

Yes ça devient sympa quand on personnalise un peu l'interface. Bon après moi je considère toujours l'interface web de la HC2 comme une interface d'administration, et pas une interface utilisateur. Donc que ça soit beau ou moche, ça ne change pas grand chose àl’utilisation, le WAF peut être identique tant que les scénarios s'exécutent

A défaut de concours d'uptime, on passe au concours de mauvaise foi

quoi ? Je ne comprends pas ce que tu veux faire avec ta scène , des triggers ?? Perso j'ai juste un VD qui envoie des ordres au module... j'avais donné toutes les commandes en LUA il y a quelques pages (identifiées grâce au mode bloc, pour une fois que c'était utile ce mode bloc ... ) C'est tout, pas besoin de plus. Après que les commandes soient dans une scène ou un VD, ça ne doit rien changer. Juste un truc qui n'a jamais fonctionné avec ce module : c'est la sonde de température. Il faut "poller" manuellement le module pour récupérer la valeur, car celui-ci ne l'envoie pas automatiquement. Et quand bien même, comme la précision est de 1°C, c'est totalement inexploitable dans un scénario. J'utilise donc un autre capteur de température dans la pièce (le bon vieux ST814, toujours aussi efficace)

@sebcbien, ta théorie, tu peux nous la traduire en LUA, ça sera plus compréhensible là @domomat bon moi je n'y connais rien à la loi, mais si j'interprète les conditions d'utilisation de Jeedom, on n'a donc pas le droit d'obtenir les sources des plugins payant sans l'acheter avant. Merci cela répond donc à ma question

Le souci de CentOS, c'est que ce n'est pas Redhat. C'est con mais c'est comme ça. Par exemple, il y a des éditeurs d'applications qui certifient leur application sur Redhat, mais pas sur CentOS. En clair : ton logiciel bug, tu appelles le support de ton éditeur, il t'envoie balader parce que tu n'as pas acheté la distrib Redhat officielle. et le terme "Red Hat Enterprise Linux customers" fait toute la différence.... bon après c'est leur business, je comprend parfaitement Mais ça a bien changé, j'ai commencé Redhat dans les années 90, c'était réellement gratuit. EDIT : désolé pour le HS total sur ton topic....

@sebcbien je sais bien pour Redhat, mais ces malins là , en plus de vendre du support, ont rendu la distribution Redhat inaccessible au téléchargement. Donc si tu ne payes pas, tu ne peux plus avoir Redhat. Il y a les solutions de contournement CentOS, mais ce n'est pas strictement la même distribution. @i-magin : ah je t'ai posé une colle

Les plugins sont tous open-source ? Si oui, alors pourquoi seraient-ils payant ? Il suffit donc de prendre le source, de le compiler, et de l'installer manuellement sur Jeedom, tout cela gratuitement, avec juste un peu d'huile de coude ? Est-ce possible ?

Ne soit pas si pressé, il leur faut au moins 1 mois de travail acharné pour livrer une nouvelle beta

Oui Jojo je suis bien d'accord avec toi C'est le service rendu aux utilisateurs qui prime. Mais souvent, la plupart des applicatifs sont arrêtés même un court instant, par exemple une fois par nuit pour les backups. Même si l'application n'est pas totalement arrêtée, elle est suspendue (Exemple un serveur Oracle en mode Begin Backup). Ce que je veux dire, c'est qu'il y a tellement de comportement différent d'une application à une autre, qu'il est difficile de trouver une mesure commune. Alors on peut parler de taux de disponibilité de l'application. Mais le uptime reste une information purement système. Un système qui reboote, sur des très gros serveurs, c'est pas loin de 1 heure ! Dans ce cas là , tu imagines que l'indisponibilité de l'application est colossale (le temps qu'elle même redémarre). Mon watchdog avait pour but de redémarrer les applications au plus vite (donc sans rebooter, même si la HC2 reboote très vite), afin que le service domotique soit toujours rendu. Que cela se passe la nuit ou le jour, au final ce qui compte c'est que je n'ai plus été indisposé par les 503 depuis que j'ai ce watchdog système. Même principe que le watchdog des Scènes+VD.

@jojo bon si on ne compte pas tous de la même façon, ça va pas aider Un uptime c'est le temps depuis lequel un serveur tourne, même si l'application est redémarrée. C'est quand même très con de la part de Fibaro de mettre leur pseudo uptime différent dans l'API. Enfin on n'est plus à une abberration près.... perso cela m'embête, car je comptais utiliser cette variable pour détecter si la box vient de booter ou seulement si les services ont redémarré, grâce à une scène au autostart. Bien sur cela n'est pas réalisable, ce "uptime" là repars systématiquement à 0, donc il est inutile.