Lazer

avec api.post c'est plus facile. Voici une fonction qui fait le job : local debug = true -- false -- -- createVG function -- function CreateVG(varName, varValue, varEnum) Message("purple", "CreateVG") local isEnum = (#varEnum > 0) and 1 or 0 local payload = {name=varName, isEnum=isEnum, value=(varValue or "")} if debug then Message("gray", json.encode(payload)) end local response, status = api.post("/globalVariables/"..varName, payload) if (tonumber(status) == 200 or tonumber(status) == 201) and response ~= nil and response ~= "" then Message("", 'Global variable "'..varName..'" created') if isEnum > 0 then local payload = {name=varName, isEnum=true, enumValues=varEnum} local response, status = api.put("/globalVariables/"..varName, payload) if (tonumber(status) == 200 or tonumber(status) == 201) and response ~= nil and response ~= "" then Message("", 'Global variable "'..varName..'" modified with enum values') else Message("red", 'Error : Can not modify enum global variable, status='..status..', payload='..json.encode(payload)..', response='..(response or "")) end end else Message("red", 'Error : Can not create global variable, status='..status..', payload='..json.encode(payload)..', response='..(response or "")) end end -- function -- Create VG local vg = "MyVariable" local variable = api.get("/globalVariables/"..vg) if not variable then if debug then Message("gray", 'Global variable "'..vg..'" does not exist') end CreateVG(vg, "", {}) elseif debug then Message("green", 'Global variable "'..vg..'" exist') end Attention dans ce code la fonction Message() fait appel à une autre fonction que je n'ai pas recopié, tu peux simplement faire un fibaro:debug() à la place

Oui tout à fait, tu devrais pouvoir écrire cela : for w = 1, #json_table["result"]["current"] do hash = json_table["result"]["current"][w]["data"][1]["a"] de la façon suivante : for w = 1, #json_table.result.current do hash = json_table.result.current[w].data[1].a et ça devrait revenir au même (pas testé, donc j'espère ne pas avoir fait d'erreur de syntaxe) Tu noteras que "w" et "1" restent entre crochets, car ce sont des indices, respectivement des arrays "current" et "data". D'ailleurs, vu que data est un array, tu peux le parcourir, ce qui donne : for w = 1, #json_table.result.current do for x = 1, #json_table.result.current[w].data do fibaro:debug(json_table.result.current[w].data[x].a or "<nil>") Remarque l'ajout de " or "<nil>"" pour éviter un plantage, au cas où la valeur n'existe pas et retournerait nil (équivalent de null ou NULL dans d'autres langage) Enfin, pour optimiser tout cela, il veut mieux éviter de compter le nombre d'élément d'un array à chaque passage dans la boucle (question de performance). Donc on fait cela : local nb_w = #json_table.result.current for w = 1, nb_w do local nb_x = #json_table.result.current[w].data for x = 1, nb_x do fibaro:debug(json_table.result.current[w].data[x].a or "<nil>") end end Pas testé non plus, mais l'idée est là.

Il n'est pas possible "d'attraper" directement la valeur data.a car data[] est un tableau (Array) Quelque chose comme ça ira mieux : data[1].a A mettre en forme dans le code LUA...

Oui je pense que c'est possible.... qui veut le faire ?

Pff, c'est nul Jeedom, même pas de plugin Unifi En fait, je n'ai implémenté que le Read, mon code LUA ne sait pas encore faire de Write pour modifier une valeur SNMP. Toute la base du protocole SNMP v1 y est, il ne manque pas grand chose pour faire de l'écriture, mais je n'en n'ai jamais eu le besoin.

Alors, vulgarisation rapide du protocole NTP : Tous les serveurs NTP sont synchronisés entre eux, les uns derrière les autres. Du fait de la cascade, on pourrait craindre une dérive, mais il n'en n'est rien, car le protocole gère une notion d'offset, qui permet à un serveur de rattraper son décalage sur le précédent. Par conséquent, quel que soit le serveur NTP qu'on utilise cela ne change rien, l'heure est toujours la même. De plus le protocole NTP gère les timezones, donc inutile de choisir un serveur NTP de votre pays, la synchro se fait en UTC (temps universel), et chaque système est responsable d’appliquer localement sa timezone et décalage d'heure été/hiver (saleté d'heure d'hiver, il va faire nuit tôt ce soir) Donc encore une fois, tout cela ne change rien, utilisez le serveur NTP qui vous fait plaisir, tant qu'il est opérationnel c'est OK. Vous pouvez même utiliser le serveur NTP de votre routeur si celui-ci le gère, ou d'un autre équipement du réseau (switch, NAS, etc)... il faut bien évidemment que celui-ci soit synchronisé sur un serveur de temps internet, et qu'il ne soit pas source de son propre temps, donc dérive inévitable à venir. Sinon, il existe des serveurs de temps qui ne dépendent pas d'Internet, et qui vont chercher l'heure dans les signaux GPS (eux-même synchronisés depuis le sol), mais ce sont des équipements couteux et pas adaptés aux particuliers. Encore que je suis certain qu'on doit pouvoir faire ça en DIY. Maintenant, le problème de la HC2, c'est que Fibaro n'a jamais activé le démon "ntpd" sous Linux, lequel est responsable de la synchro en temps-réel. Par conséquent, quel que soit le serveur NTP que vous choisissez dans l'interface Web, au moment de l'enregistrement, une synchro est faite, et c'est tout. La suivante se fera lors du reboot, d'un backup (lequel provoque un redémarrage de tous les services Fibaro, presque similaire à un reboot), ou du prochain enregistrement NTP (ce qui provoque un reboot). Pour info, le VD Clock Sync force un enregistrement manuel, d'où le reboot. Bref, c'est solution est sans fin, tant que Fibaro n'activera pas le démon NTP, les box sont condamnées à dériver dans le temps. Ce qui est aberrant....

Tiens, c'est vrai ça, pourquoi Clarity est dans Bistro et pas dans "Périphériques et matériels autres" ? Mais maintenant qu'on y parle vin, il a toute sa place dans le "Bistrot". Remarque, vu le nombre de sujets où on parle Bières, Mirabelle, & co, beaucoup pourraient se retrouver dans le Bistrot

De mon coté, je n'ai pas de souci, tout remonte : la sonde intérieur, la sonde extérieure, et le pluviomètre extérieur. Etrange votre bug, vous l'avez remonté à Fibaro ?

J'ai de plus en plus l'impression que la France fait partie du "reste du monde" et pas de l'Europe, c'est inquiétant. Quand on voit les smartphones Google Pixel qui sont dispos en UK, DE, mais aussi IT et ES, mais par en FR, maintenant Neeo va nous faire le même coup :/ Enfin, les télécommandes arriveront, mais après.

Oui i-magin, c'est moi qui a fait le déplacement dans la section multimedia

Perso, je ne suis pas trop d'accord, c'est un forum de domotique ici, et il y a déjà un forum entier dédié à Xpenology. D'ailleurs je ne comprends pas vraiment l'intérêt de ton dernier sujet dédié aux loaders, que tu as entièrement pompé sur le forum original.... Sans compter que le projet Xpenology surfe toujours à la limite de la légalité.... c'est légal, mais l'usage qui peut en être fait ne l'est pas forcément (licences SS, etc) A la limite une section "informatique" (serveur, réseau, wifi, etc) aurait un sens sur le forum, mais à l'époque où on en avait parlé, Yohan n'était pas d'accord, il préférait qu'on utilise la section "Multimedia" plus générique.

Ou alors, voir dans le panneau d'événement, chercher l'info. /api/events

L'Update 1 pour ESXi 6.5, c'est Krkri qui t'as donné le lien. Pour la 6.0, l'Update 3 est probablement la dernière, je ne sais pas trop, je ne surveille pas les évolutions.

Hey Jojo, t'es pas chez Fibaro là, si VMware a publié la 6.5, c'est qu'elle est stable En plus il y a déjà l'Update 1, donc si gros bugs il y avait, ils sont corrigés. Par contre, les entreprises, elles, n'aiment pas être à la dernière version, j'ai peu de clients qui sont passés en 6.5. La plupart sont encore en 6.0, et il y en a encore quelques uns en 5.5. Par rapport à ton message, l'ISO préparé par HPE, c'est bien pour faire une nouvelle install, ou une migration (changement de version 5.5 => 6.0 => 6.5). Si tu veux juste faire un Update au dernier niveau de patch de ta version en cours, il faut mieux prendre les packages de mises à jours partagés par VMware.

Très astucieux, bravo

Ah mais t'as rien à dire, de toute façon tu aurais encore trouvé des excuses à Fibaro, alors qu'ils continuent à tourner en rond dans leur coin... PS : sérieusement la vraie nouveauté, c'est la vanne thermostatique, heureusement qu'ils ont annoncé ça par surprise le mois dernier, pour montrer qu'ils existent encore !

Sinon l'autre solution, si c'est un PI ou tout autre machine sur laquelle on a la main, c'est de mettre un serveur Web avec PHP qui exécute les commandes désirées, ainsi il n'y a plus de limites. Et la HC2 sait faire des requêtes HTTP en toute simplicité.

J'avais fait une longue réponse, mais elle a disparu (regarde si tu ne l'a pas vu passer dans tes emails de notification) En résumé : pas de SSH, mais TELNET OK =>

Heureusement que @Nico nous avait prévenu que les vraies nouveautés arrivaient, sinon j'aurais été totalement estomaqué par cette longue liste de nouveautés inédites

C'est bien connu le bon coin, tu as un prix de vente, négocié à la baisse par téléphone, et puis le jour de la transaction l'acheteur se pointe toujours avec 10€ en moins dans la poche... à prendre ou laisser. Bref, les prix affichés ne veulent pas dire grand chose !

Bien résumé Pas tout à fait, un téléphone IP alimenté en POE a besoin du gigabit, non pas pour son propre besoin, mais pour le PC branché derrière. Idem pour une borne Wifi AC, qui dépasse le 100Mbits. C'est donc une bonne chose que Ubiquiti abandonne son vieux POE Passif propriétaire, mais attention, il en traine encore (notamment chez moi dans mon EdgeRouter POE 5 ports)

Attentionn, cela est valable car ce switch gère " 4 Auto-Sensing IEEE 802.3af PoE Ports " Sur d'autres switchs de chez Ubiquiti, ils n'ont pas de POE standard, mais du POE propriétaire qui ne négocie pas la tension.... donc ne rien brancher d'autre sous réserve de cramer quelque chose.

Euh pas du cache, qui est installé par défaut sur le carte RAID PCI, mais plutôt la batterie qui permet d'activer ce cache. C'est là ce qui fait le gain de performance.

Bof oui et non. Pour un benchmark c'est vrai. En pratique, sur ce serveur, tu 'e gagneras rien, car sur le SSD, tu vas y mettre le datastore, donc l'OS des VM, et le gain se fera par le temps d'accès très faible des SSD. Le débit maximum du SATA 2 n'aura donc pas d'impact. Sinon pour le G8, il y a un contrôleur RAID intégré, mais qui ne fait que du Raid 0 et 1. Si vous voulez faire du raid 5, il faut la carte Pci, et pensez aussi à ajouter du cache

Avec des disques durs, tu ne verras pas la différence SATA 2 ou 3 puisque le débit de tous les disques est inférieur à 300Mo/s, et de loin. Perso je ne suis pas partisant du raid dans un NAS, donc pas de carte du tout ! Mais sinon, dans le G8, il y a une liste de compatibilité, sans quoi le ventilo tourne trop vite et fait du bruit. Je crois que la p222 est OK,, mais faudrait vérifier....