Barelle

Quand j'étais petit, Dell avait déjà mauvaise réputation, IBM imposait l'uniforme, Dec avant son rachat était apprécié, HP ne vendait en France que des instruments de mesure... La dégradation des conditions de travail, trouve, selon moi, sa source dans les orientations politiques largement diffusées par les grands cabinets de conseil américains auprès des entreprises et de certains gouvernements (en France sous Sarko), on y retrouve des aspects pertinents (KISS, tout ce qui se mesure s'améliore...) mais aussi des dogmes (big is beautiful, l'unité de mesure comprise par tout le monde est monétaire, do more with less...). Ces idées brillamment diffusées auprès des DG ont peu à peu envahi le monde de l'entreprise et les écoles de commerce ou d'administration. Cela a débouché vers le développement d'un système financiarisé à outrance où les dividendes versés aux actionnaires deviennent un objectif qui prime sur la qualité du service rendu au client ou sur la vision industrielle qui elle s'inscrit dans le temps long. On assiste donc à une partition (accentuée par le code des marchés publics) avec d'un coté les grandes sociétés (ou organismes) qui confient leurs grandes commandes aux grandes entreprises, et de l'autre les PME, qui hésitent moins à confier des travaux à des boites plus humaines. Mais dès qu'une petite entreprise devient attractive, elle se fait racheter par une plus grosse, c'est d'ailleurs très souvent l'objectif des startuppers qui exploitent sans vergogne de jeunes développeurs en leur faisant miroiter des avantages et un état d'esprit (baby-foot, massages...) et qui s'empresse de faire la culbute dès que leur bébé a acquis suffisamment de notoriété pour être vendu ; l'acquéreur, fréquemment, se dépêchant de fermer sa nouvelle acquisition en l'accusant de défaut de rentabililité. Il existe des contre-exemples comme Fibaro ou Netatmo, pour notre domaine d'intérêt. Désolé d'avoir pourri ton post sur l'onduleur connecté.

Encore mieux que la société de service, le constructeur : cours abondants (aux US ou en UK), avec dès que son expertise est reconnue, accès aux usines de matériel ou de logiciel et donc à des informations ou à des concepts qui prennent forme plus de 10 ans plus tard (j'ai dû entendre parler des messages broker pour la première fois vers 87 ou 88), et là aussi, si on a su acquérir un certain poids reconnu, une autonomie totale, sauf pour l'engagement de moyens au delà d'un certain seuil où, comme partout, il faut monter un dossier. A une époque, dans les services centraux d'un grand producteur d'électricité, plus gros embaucheur d'ingénieurs en France, les moyens techniques étaient plus que conséquents. Comme dans toute les grosses structures, il y a toujours un service prévu pour réaliser tel ou tel travail, et donc une surcharge pondérale de l'administratif (cf. le principe de Parkinson dont nous souffrons nationalement). A l'opposée, dans une PME, les moyens limités obligent à faire soi-même un grand nombre de tâches, ce qui est beaucoup plus valorisant. Sur le télétravail, j'ai expliqué pendant des années que les projets open source étaient souvent développés par des gens qui ne sont jamais rencontrés et que rien n'interdit de s'inspirer de ce type d'organisation (en réseau) pour la conduite de gros projet (en rémunérant au forfait les développeurs de telle ou telle fonction), je confesse n'avoir eu aucun succès face à des managers (surtout chez les clients qui assoient leur autorité sur la largeur et la profondeur du râteau de leurs subalternes)

Non, jamais syndiqué, 16 ans chez un constructeur, second mondial à une époque, 20 ans en société de service, support client en système, transactionnel et réseau, consultant, directeur de projets, homme à tout faire , spécialiste des cas désespérés, retraité, et citoyen légaliste. La plupart des société de services sont des marchands de temps de travail (de viande quoi, surtout les plus grandes) qui, confrontés à la dictature du TJM, exploitent ouvertement des armées de petits jeunes, souvent en reconversion. Nous croulons sous les lois et règlements qui nous coûtent un pognon de dingue, s'ils ne sont pas respectés, c'est de l'argent jeté par la fenêtre... Après, l'autonomie des cadres, dans la mesure où leur contrat de travail prévoit la fixation d'objectifs, peut être totale, cela dépend du management. J'ai pu constater que, quelle que soit l'entreprise, privée ou publique, les commerciaux bénéficient toujours d'une plus grande autonomie que les ingénieurs, va savoir pourquoi ? Sans doute la part fixe de leur rémunération étant plus faible... Mais on revient là au contractuel, donc au légal...

Une boite de service, cela n'explique en rien l'activité réalisée... Que comme tout bon geek, on aime se faire plaisir avec du beau matériel tout neuf, cela ne fait aucun doute. Hors circonstances exceptionnelles, le télétravail est principalement fonction du type d'activité, du client et bien sûr de la politique de l'entreprise. Il faut ajouter que légalement, l'employeur doit indemniser les moyens engagés par le salarié à son domicile : remboursement au prorata de l'abonnement internet, moyens informatiques, mobilier... Enfin, toujours selon le type d'activité et les moyens auxquels le salarié doit accéder, le télétravail représente une faille de sécurité potentielle nécessitant une étude particulière.

C'est exact, on peut également considérer : - que le délai d'arrêt du Nas est paramétrable ; - que rien n'interdit de brancher la box domotique sur l'UPS ; - qu'il est ainsi totalement possible de gérer l'arrêt du Nas par la domotique ; - et que le télétravail n'impose pas d'investir dans un datacenter at home.

S'ils sont connectés (en USB) à un NAS Synology, DSM intégrant un serveur UPS, on peut récupérer l'état des modèles Ellipse PRO.

Il est nécessaire de conserver le port 3493, celui du serveur UPS du NAS.

Il ne faut pas changer le code utilisateur et le mot de passe, en conservant le port 3493.

__fibaroSceneId n'a pas été reconduit sur HC3 ?

Pour la journée, il faut bien un all, mais pour la nuit il faut un any.

Dans ma compréhension, all correspond à un et logique des conditions et any à un ou logique. A une heure du matin, nous sommes bien avant le lever du soleil et avant le coucher du soleil, donc avec all la condition n'est pas remplie, ce n'est pas la nuit !

Ben non, à minuit, on est au milieu de la nuit . Donc entre le coucher du soleil et minuit, c'est la nuit, OU, entre minuit et le lever du soleil. Une seule de ces conditions suffit.

C'est sûr, c'est la même application qui est loin d'être parfaite mais qui fait malgré tout le boulot.

Le portier vidéo Hikvision DS-KIS701 est livré avec un écran, et on peut en rajouter jusqu'à 8...

Il y a l’embarras du choix : L'écrire dans une variable globale pour la relire dans la scène. L'écrire dans un label de VD à relire dans une scène. Passer la valeur en paramètre lors du lancement de la scène par un VD. Récupérer directement la valeur à partir de la scène.

Nouvel essai : local thisdevice = fibaro:getSelfId() local sensorName = "pirdupir"; local conn = Net.FHttp(fibaro:getValue(thisdevice, 'IPAddress'), fibaro:getValue(thisdevice, 'TCPPort')) -- connection espeasy/port response, status, errorCode = conn:GET('/json') fibaro:debug(response) if tonumber(status) == 200 then jsonTable = json.decode(response); -- decodage de la table json espeasy for _, sensors in ipairs(jsonTable.Sensors) do fibaro:debug("sensors=".. json.encode(sensors)); if sensors.TaskName == sensorName then for _, row in ipairs(sensors.TaskValues) do fibaro:debug("row=".. json.encode(row)); sensorValue = row.Value; fibaro:debug("Nom du capteur=".. row.Name..", valeur="..row.Value); break; end end end else fibaro:debug("error, status="..status) end

C'est curieux, la requête avec tasknr retourne un json invalide. donc, on va utiliser la requête json qui retourne un max de données : local thisdevice = fibaro:getSelfId() local sensorName = "pirdudir"; local conn = Net.FHttp(fibaro:getValue(thisdevice, 'IPAddress'), fibaro:getValue(thisdevice, 'TCPPort')) -- connection espeasy/port response, status, errorCode = conn:GET('/json') fibaro:debug(response) if tonumber(status) == 200 then jsonTable = json.decode(response); -- decodage de la table json espeasy for _, row in ipairs(jsonTable.Sensors.TaskValues) do if row.Name == sensorName then sensorValue = row.Value; fibaro:debug("Nom du capteur=".. row.Name..", valeur="..row.Value); break; end end else fibaro:debug("error, status="..status) end

Avec cela, on ne devrait pas être loin du résultat attendu : local thisdevice = fibaro:getSelfId() local taskId = "1" local conn = Net.FHttp(fibaro:getValue(thisdevice, 'IPAddress'), fibaro:getValue(thisdevice, 'TCPPort')) -- connection espeasy/port response, status, errorCode = conn:GET('/json?tasknr=' .. taskId) fibaro:debug(response) if tonumber(status) == 200 then jsonTable = json.decode(response); fibaro:debug("Nom du capteur=".. jsonTable.TaskName..", valeur="..jsonTable.TaskValues.Value); else fibaro:debug("error") end

Dans ce cas, il est tout à fait normal que cela ne fonctionne pas, le code servant à récupérer les valeurs de température et d'humidité d'un capteur DHT22.

Les goûts et les couleurs... C'est comme les téléphones, certains ont le design et d'autres les fonctionnalités...

Dans la réponse de l'ESP Easy, il n'y a aucune valeur ressemblant à une température ou une humidité, as-tu bien un capteur qui y est connecté et qui y est déclaré ?

Je l'ai acheté, mais non encore installé définitivement. Le principal avantage que je lui ai trouvé et le fonctionnement sur 2 fils seulement. Il est vu sur le réseau comme une caméra Hikvision, avec la possibilité d'en enregistrer le flux. Une notification est remontée sur smartphone dans l'application Hik-connect. Par contre, je n'ai pas encore testé l'interface avec la HC2.

La réponse ne comprend pas les champs Temperature et Humidity, il faudrait changer la requête : response, status, errorCode = conn:GET('/json?tasknr=' .. taskId) en response, status, errorCode = conn:GET('/json') puis, reposte le debug.

Le mien datait de janvier 2016, du jour au lendemain, il s'est mis à consommer des piles à vitesse accélérée (moins de 24 heures) malgré un nettoyage approfondi. Manifestement il y a un défaut d'étanchéité que j'avais déjà eu sur l'anémomètre, ce dernier avait été remplacé au titre de la garantie. Quant au plastique, il vieillit relativement mal. Etat intérieur :

Ainsi, cela devrait mieux fonctionner : fibaro:debug("toto: "..jsonTable0.weather[1].description)