Krikroff

Tu as repris le code d'ici ? https://www.domotique-fibaro.fr/topic/107-wake-on-lan-wol-dã©marrer-son-ordinateur-ã -distance/ Net.FUdpSocket() n'est tout juste pas supporté

Non tu as bon, car l’API retourne une liste de device

Tu peux essayer avec [‘id’] à la place de .id

Pourtant je crois voir l’ID dans la réponse dans la scène, à la fin non ? ID 136

Tu peux essayer ceci dans une nouvelle scène LUA et en adaptant local x = api.get("/devices/?name=DEVICE_NAME_XXX") print(json.encode(x))

Étrange cette affaire

Si si logiquement cela fonctionnement très bien ! Si tu essaies directement via ton navigateur de la manière suivante http://xxx.xxx.xxx.xxx/api/devices/?name=DEVICE_NAME_XXX

Débranche internet voir si ça fonctionne localement...

Sous Android je n’ai pas d’expérience, sous iOS (iPhone 7) c’est stable et fluide. Ma question précédente était dans l’idée d’identifier un possible problème au niveau des serveurs SIP Fibaro, la previsualisation elle utilise le flux mjpeg directement

@mprinfo, idem ubiquiti 16 ports poe Nous sommes d'accord sur le système de connexion mais une fois en place il n'y a pas de raison, surtout que cela semble fonctionner parfaitement avec mon application... @mprinfo, tu rencontres le problème dans quel(s) cas: - Prévisualisation ? - Mode preview puis tu décroches ? - lorsque tu réponds à un appel ?

Très intéressant mais clairement pas donné en effet ! Les prix baisseront, pour le moment pas besoin de changer en ce qui concerne

L’avantage c’est qu’il tournera toujours

Yesss [emoji4]

L’idée, tu fais une scène avec un interval d’une minute tout le reste est fait dans ta scène

Je vois bien ce que tu veux dire pfffff Ok cette fameuse histoire de réveil ou il faudrait pouvoir utiliser une variable global dans les conditions c'st bien cela ? Alors, ce que je pense: - Il me semble très plausible (voir j'en suis convaincu) que le garbagecollector recycle le pool dans lequel est ta scène et donc le timer est tué. C'est même une pas trop mauvaise pratique évitant ainsi à Fibaro de faire trop de support .... - La solution: remplace ton setTimeout qui boucle toutes les minutes par un cron et conserves le reste

Réunion de crise aujourd’hui au taff mais pas de temps libre à l’horizon... projets et continuité de service oblige [emoji51]

Hum [emoji848] un numéro de série inférieur à 500. Elle était emballée sous cellophane ? Quelle version de firmware à la première mise sous tension ?

Tu peux poster ta scène ? Pourquoi un setTimeout ?

396 [emoji15] achetée où ?

PTDRrr 30 jours perfusé à la corona, c’est clair ça va envoyer [emoji51][emoji51]

C’est dans les tuyaux mais malheureusement je ne peux pas m’avancer sur une date de mise à disposition pour le moment

Tu as raison, ton problème est résolu c'est l'essentiel.

Je l'ai constaté régulièrement sur HC2, du coup ça confirme bien ce que je pense depuis un petit moment à savoir qu'une très grosse partie du HC3 = HC2 voila voila et la marmotte elle met le chocolat dans le papier d'alu ...

Peut-être simplement parce que le callActionGroup est codé avec les pieds Si cela fonctionne local ListeLightsInRoom = api.get("/devices/?roomID="..roomID.."&property=[isLight,true]") for k,v in pairs(ListeLightsInRoom) do fibaro.call(v.id, "turnOff") --turnOn end C'est une solution plus qu'acceptable !

Ceci est la bonne solution, tu ne pourras jamais faire la même chose avec un callActionGroup De plus derrière un callActionGroup il n'y que du lua donc même pas un gain de performance.