base de connaissances Gestion des appareils enfants

[MAM78]

@jjacques68 merci pour la proposition. Je reviendrais vers toi dès que je pourrais me pencher sur le sujet. Mais dans l'immédiat je vais essayer de terminer le Quick App Doorbird Manage.

[Lazer]

il y a une heure, MAM78 a dit :

il n'est plus nécessaire mettre en claire les mots de passe dans les requêtes push de l'IPX

Euh.... j'espère que personne ne met son mot de passe admin sur les autres appareils que la HC2/HC3 elle-même.

 

TOUJOURS créer des utilisateurs dédiés, avec mot de passe spécifique, et droits restreints aux seuls et uniques modules pouvant être accédés en lecture/écriture.

 

C'est bien simple, chaque appareil devant se connecter sur la box domotique dispose de son propre compte qu'il ne partage avec aucun autre.

Exactement comme pour un humain (chacun son compte sur l'application mobile de son smartphone)

 

Cette règle est valable tout le temps, pas que pour la box domotique : sur le NAS Synology/QNAP, Unifi Controller, etc...

 

Pratique de sécurité de base

 

 

 

Après pour les sockets, ouais .... ça fait du boulot en plus, pour un truc qui ne fonctionne qu'avec l'IPX800, ça teste un palliatif, comme dit, ça ne vaut pas les vrais Websockets standardisés....

Bref on verra plus tard, déjà faire en sorte que ça fonctionne.

 

[jjacques68]

il y a 21 minutes, Lazer a dit :

 

TOUJOURS créer des utilisateurs dédiés, avec mot de passe spécifique, et droits restreints aux seuls et uniques modules pouvant être accédés en lecture/écriture

complètement d'accord.

 

[MAM78]

Nous sommes en phase, mais cela n'empêche pas que le mot de passe en question reste lisible sur les trames réseau et pas simple à maintenir lors de son renouvellement. Si l'on peut éviter c'est toujours mieux, non ?

 

D'autant que si quelqu'un chope le login/psw, il pourrait faire certaines choses qui ne serait pas très agréables. Limité mais quand même.

 

 

Modifié le 16 décembre 2020 par MAM78

[Lazer]

Certes oui, mais la transmission du mot de passe est inévitable.

 

La technique que je donne (qui n'est pas la mienne évidemment), présente les intérêts suivants :

- quand le mot de passe est compromis, l'attaquant n'a accès qu'à un nombre très très limité de ressources, puisqu'on applique la politique du "rien" par défaut, et on ajoute spécifiquement les droits nécessaires

- le changement du mot de passe est très simple puisqu'un seul appareil (ou humain) est impliqué, sans devoir faire la tournée de X machines pour mettre à jour le-dit mot de passe

 

Si tu veux limiter grandement les risques, c'est là que la HC3 devient intéressante, car tu peux faire du https, donc théoriquement inviolable. Encore faut-il que l'appareil client en face le supporte. Cela semble être le cas de l'IPX800 v4 en cochant la case SSL (je n'ai pas testé)

 

Bon après on parle d'un réseau local personnel, qui n'intéresse aucun attaquant. Et quand bien même tu aurais ta box domotique sur un réseau d'entreprise, cible d'un attaquant, il a autre chose à faire de ta domotique, ce sont les données de ton serveur qui vont l'intéresser.

Toujours est-il que la box domotique ne devrait jamais être exposée en direct sur Internet via une redirection de port, http ou https cela ne change rien, si la faille se situe dans le serveur Web (Apache, Nginx, Lighthttpd, etc).

Ma box est derrière un reverse proxy filtrant analysant toutes les requêtes avec un firewall applicatif (WAF), lui-même situé en DMZ. C'est déjà mieux.

De toute façon vu que Fibaro ne permet plus d'attaquer l'IP des Home Centers en direct depuis les applications mobiles, j'ai envie de dire, problème résolu, il n'y a plus guère d'intérêt à accéder à la box en direct.

 

Bon tout cela est HS, devrait être sur un topic dédié, et de toute façon ça a déjà été dit plusieurs fois sur le forum.

[jjacques68]

petite question : 

 

on a souvent une fonction pour créer les child dans le parent.

Comment peut-on faire, si on re-exécuté cette fonction, pour ne pas qu'il recrée les child déjà créé ?

 

il faut checker les child existant et comparer le nom ? ou y a un autre moyen ?

[Lazer]

Absolument, j'ai envie de dire qu'il faut "obligatoirement" vérifier l'existence éventuelle de chaque Child avant de créer le nouveau.

Sinon ça va être l'horreur quand l'utilisateur va cliquer frénétiquement sur le bouton. Et faut pas espérer toucher les allocs ou la carte famille nombreuse....

 

Je connais un seul moyen d'identifier chaque child de manière unique : en stockant un identifiant dans ses variables.

Par exemples :

- pour la station Netatmo, on y stocke l'ID unique attribué par Netatmo à chaque module.

- pour un IPX800 ou un EcoDevice, je stocke l'identifiant du port d'E/S : R1, R2, .... D1, D2, .... A1, A2, .... etc

- pour Surveillance Station : l'ID de la caméra donné dans l'API de Syno.

- etc

 

Extrait de code :

-- On veut créer un child
local exist = false
for _, child in pairs(self.childDevices) do
	-- On test si le child existe déjà (ce test est totalement dépend de chaque QuickApp qu'on développe)
	if pinFullName == pinNames[dev.pinName].getPin(tools.getVariable(child, "pinName"), tools.getVariable(child, "pinNumber")) then
		self:debug("Child device #" .. tostring(child.id) .. " <b>" .. child.name .. "</b> already exists for pin <b>" .. pinFullName .. "</b>")
		exist = true
		break
	end
end
if not exist then
	-- OK on peut créer le child...
end

En fait cet extrait s'intègre dans une autre boucle qui parcoure elle-même la liste des enfants à créer.

Le tout est dans une fonction appelée lors de l'appui sur un bouton du QA.

 

[jjacques68]

ok j'ai compris.

vais mettre cette sécurité dans mes QA.

merci !!

[Dragoniacs]

J'ai une question sur la personnalisation des modules enfants.

Je suis en train de mettre en QA la gestion de mes VELUX (via le KLF200). Je gère chaque volet comme un child, ce qui est super pour alléger le code et la charge du réseau wifi. Mais par contre, ils sont un peu moches, car j'ai pris le type "multilevelswich".

Savez vous si je peux changer le label "Brightness" en "Ouverture", et le "On/Off" en "Ouvert / Fermé" ? ou le "PowerSwich" en "Mode" (ou un truc du genre....)

[jjacques68]

ça marche pour les boutons, alors peut-être que ça peut aussi marcher :

self:updateView("le_nom_de_l'objet", "text", "ton_texte")

à essayer...

 

le ON/OFF, je pense pas.

Modifié le 29 décembre 2020 par jjacques68

[Dragoniacs]

Faut que je regarde dans le détail du QA pour connaître les noms des objets alors....

Envoyé de mon RMX1993 en utilisant Tapatalk

[jjacques68]

oula attend, je plane, j'ai pas fait gaffe que c'était l'interface par défaut !

Je pensais au object que l'on ajoute dans un QA autre que Child.

 

Désolé, ben nan, la je crois que ce sera pas possible.

 

A moins que qqun ait une autre idée...

Modifié le 29 décembre 2020 par jjacques68

[Lazer]

Tu devrais tout simplement prendre le type com.fibaro.rollerShutter

 

 

[Dragoniacs]

Ah ouai merde, pas con.....


Envoyé de mon RMX1993 en utilisant Tapatalk

[jang]

Everything I (currently) know about QuickAppChildren ...

https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/?do=findComment&comment=223530

 

Modifié le 30 décembre 2020 par jang

[Lazer]

Very interesting, thank you

 

[jjacques68]

thank @jang, very good.

I must read it many times.

And make some tests to understand all  

[Lazer]

Le 17/05/2020 à 12:00, jang a dit :

With my fibaroapiHC3.lua sdk I automatically crate a proxy on the HC3 for my QuickApp (running in ZeroBrane studio).

The proxy QuickApp sends all actions/ui events back to the code in ZBS. A procy looks like:

local function urlencode (str) 
  return str and string.gsub(str ,"([^% w])",function(c) return string.format("%%% 02X",string.byte(c))  end) 
end
local function POST2IDE(path,payload)
    url = "http://"..IP..path
    net.HTTPClient():request(url,{options={method='POST',data=json.encode(payload)}})
end
local IGNORE={updateView=true,setVariable=true,updateProperty=true} -- Rewrite!!!!
function QuickApp:actionHandler(action) 
      if IGNORE[action.actionName] then 
        return self:callAction(action.actionName, table.unpack(action.args))
      end
      POST2IDE("/fibaroapiHC3/action/"..self.id,action) 
end
function QuickApp:UIHandler(UIEvent) POST2IDE("/fibaroapiHC3/ui/"..self.id,UIEvent) end
function QuickApp:CREATECHILD(id) self.childDevices[id]=QuickAppChild({id=id}) end

function QuickApp:onInit()
 self:debug('Proxy Holidays',' deviceId:',self.id)
 IP = self:getVariable('PROXYIP')
 function QuickApp:initChildDevices() end
end

QuickApp:actionHandler / QuickApp:UIHandler

Hi @jang

 

I would like to intercept events on my QuickApp with child devices.

So I have defined a custom QuickApp:actionHandler() function as shown below.
Do you think it's OK regarding handling events for both parent and child devices, with no side effect, or am I wrong ?

function QuickApp:actionHandler(action) 
	if action.actionName == "removeChildDevice" then
		-- do some stuff ...
	end
	if action.deviceId == self.id then
		return self:callAction(action.actionName, table.unpack(action.args))
	else
		return self.childDevices[action.deviceId]:callAction(action.actionName, table.unpack(action.args))
	end
end

 

[jang]

Il y a 11 heures, Lazer a dit :

Hi @jang

 

I would like to intercept events on my QuickApp with child devices.

So I have defined a custom QuickApp: actionHandler () function as shown below.
Do you think it's OK regarding handling events for both parent and child devices, with no side effect, or am I wrong?

 

It should work. Be careful if chidId doesn't exist (just removed). HC3 logs a warning if ID doesn't exists.

What are you doing with 'removeChildDevice' ?

[Lazer]

OK thank's

 

I have a mapping table for my child devices.

This table is quite heavy to build, as it stores a lot of information.

To speed up execution, instead of rebuilding this table on every loop (every 60 seconds or less), I think it's more efficient to rebuild this table only on special occasions : upon Quickapp startup, child creation (when user clicks on dedicated button), or child removal (when user removes them in the HC3's devices panel)

This last case is out of scope of QuickApp events, so by being able to catch them, the QuickApp will know when to rebuild the mapping table.

 

You're absolutely right about child existence, I must add a test condition.

[jang]

2 hours ago Lazer said:

OK, thanks

 

I have a mapping table for my child devices.

This table is quite heavy to build, as it stores a lot of information.

To speed up execution, instead of rebuilding this table on every loop (every 60 seconds or less), I think it's more efficient to rebuild this table only on special occasions: upon Quickapp startup, child creation (when user clicks on dedicated button), or child removal (when user removes them in the HC3's devices panel)

This last case is out of scope of QuickApp events, so by being able to catch them, the QuickApp will know when to rebuild the mapping table.

 

You're absolutely right about child existence, I must add a test condition.

When a child is deleted (from Lua or UI) you get a 'DeviceRemovedEvent' in / refreshStates

The QuickApp will also update the self.childDevices table.

Why don't you store your extra info in the child table?

self.childDevices [childID] .extraInfo = ...

it's just the child instance

 

I don't think r emoveChildDevice (...) is called by the QA if you delete the child in the UI.

Modifié le 4 janvier 2021 par jang

[Lazer]

Yes i know about "DeviceRemovedEvent" in /api/refreshStates, but I'm afraid that monitoring this API from multiple QuickApps may slow down the system.

I also know your webhook QD, but sorry I don't want to use it for now, as I want to share standalone QuickApps on this forum, that do not depend on another external QA.

 

I already store extra information in each child instance.

But I don't want to browse self.childDevices on every loop, because if a child has been removed from UI, then it will simply does not show when browsing this table using pairs(). And my mapping table will still references this deleted child, thus will trying to update it.

 

I will do some tests with QuickApp:actionHandler() tonight to check if it performs well...

[jang]

Il y a 12 heures, Lazer a dit :

Yes i know about "DeviceRemovedEvent" in / api / refreshStates, but I'm afraid that monitoring this API from multiple QuickApps may slow down the system.

I also know your webhook QD, but sorry I don't want to use it for now, as I want to share standalone QuickApps on this forum, that do not depend on another external QA.

Fair enough. 

I stand corrected, removeChildDevice() is called when children are deleted in the IU, so the onAction hook will work.

You could also intercept calls to the method.

 

function QuickApp:onInit()

  local orgRemoveChildDevice = self.removeChildDevice

  function self:removeChildDevice(id)

     self:debug("Child ",id," is about to be deleted")

     -- do other stuff

     orgRemoveChildDevice(self,id)

  end

end

[Lazer]

I confirm that "removeChildDevice" is caught correctly using the QuickApp:actionHandler() function described above.

In fact, it isn't necessary to check child existence when forwarding action to child devices, because HC3 calls the QuickApp:actionHandler() only for Parent QA and it's own children ID's.

Once a child has been deleted, the function is not called anymore for this particular child device ID.

It means that the following function may be used to intercept any action :

function QuickApp:actionHandler(action) 
	if action.actionName == "removeChildDevice" then
		-- do some stuff ...
	end
	if action.deviceId == self.id then
		return self:callAction(action.actionName, table.unpack(action.args))
	else
		return self.childDevices[action.deviceId]:callAction(action.actionName, table.unpack(action.args))
	end
end

 

 

By the way, I love your new suggestion using QuickApp:removeChildDevice() redefinition.

It works very well, and I think it's more efficient to intercept only this particular action than all actions in actionHandler()

Thank you for your suggestion

 

[MAM78]

Lorsque nous effectuons des évolutions de nos Quick Apps et que nous les partageons avec la communauté, les modifications que nous apportons peuvent amener à modifier la configuration et propriétés des Childs et du coup la nécessité de :

• devoir supprimer l'ancienne version et recharge le nouveau QuickApp,
• regénérer les Childs,
• recommencer le paramétrage des variables,
• perdre les informations contenues dans les variables et état du Quick App et ses Childs
• corriger les autres composants qui utilisaient les ID des Childs,
• reconfigurer les icônes,
• refaire la paramétrage de la room

Afin de limiter ces problématiques, je souhaiterais trouver une solution visant à actualiser automatiquement la configuration et les propriétés des Childs et restaurer les anciennes valeurs qui devraient l'être.

 

Soit transposer la fonction createChildDevice par un équivalent UpdateChildDevice.

 

Je suppose que pour les properties, ça ne devrait pas trop poser de problèmes (à confirmer), mais quid de : name, type, initialProperties, initialInterfaces, visible, enabled, ...

 

Cf. la liste les propriétés ci-dessous. Est-ce quelles sont accessibles qu'au moment de la création ou par la suite également ?

 

 

Pourriez-vous m'éclairer sur les impactes ou limites de créer une telle fonction ?

 

Si vous l'avez déjà développé, je suis preneur de votre code.

 

@Lazer @jang n'auriez-vous pas déjà crée une telle fonction (tools) ?

 

 

Modifié le 23 novembre 2021 par MAM78