sbv1307

Jeg har fået Home Assistand installeres som Docker Container på Raspberry Pi og 2 IHC controllerer til at fungere. Jeg fik stor hjælp fra:

Hej Mikkel Har nu nørded en del, men bliver ved med at finde nye udfordringer. Du skriver: " jeg udvikler og bygger kun images vha. docker". Hvilket image (OS) bygger du ud fra (Hvad bruger du i Dockerfilens FROM linie)? Jeg tænker, det vil give mest mening, at jeg med samme image som dig, hvis der er muligt:-) Så kan andre måske også have glæde af mit projekt. Med venlig hilsen Steen Vemmelund

Hej Mikkel Jeg prøver jo at få en "Rigtig nørded variant" af ihccaptain installationen til at virke igen. Jeg har to Ihccaptain "servere" kørende i samme doccker container, som fungerer ganske fint - bortset fra det vigtigste - Philips HUE integrationen... Du har tidlige foreslået at prøve Beta versionen! Findes der et install schript (ala http://jemi.dk/ihc/files/install) til Beta versionen som jeg kan få fingrene i? Med venlig hilsen Steen Vemmelund

Det lyder lovende. Har du et bud på, hvornår I når til en release? Med venlig hilsen Steen Vemmelund

Hej Mikkel - Så er jeg tilbage efter en længere køretur (4 mdr.) - Hvordan går det med den nævnte beta, den der bruger begge metoder til at addressere Philips HUE? Med venlig hilsen Steen Vemmelund

Hej Thomas Sådan som jeg forstår IHC Captain's integration med Philips HUE, så anvender IHC Captain processen med discovery.meethue til at lokalisere Philips HUE Bridges på nettet. Så, når discovery.meethue fejler, fejler IHC Captain's funktion, der forbinder IHC Captain til Philips HUE. IP adresserne på mine Philips HUE Bridges, kan jeg godt finde med discovery.meethue - når linket virker, men typisk virker linket kun et til to gange, hvorefter det fejler. Efter en stykke tid (en kop kaffe's tid), virker linket igen, et par gange. Og - Ja, indsætter jeg IP addresserne i chrome brovseren, får jeg forbindelse. Men desværre ser det ikke ud som om, man kan indsætte ipadressen i IHC Captain's configurationsfiler.

Hej Thomas Tusind tak for response! Udfordringen er at https://discovery.meethue.com/ ofte viser: --- This page isn’t working If the problem continues, contact the site owner. HTTP ERROR 429 --- Derfor mistænker jeg, at styringen af HUE fejler. Jeg læste i en tråd, at antallet af kald til discovery.meethue var begrænset, såldes at der indenfor et tidsrum kun kan foretages et begrænset antal kald. Nu ved jeg ikke hvordan Mikkel har implementeret styringen af HUE. Jeg formoder at han har fulgt guidelines fra developers.meethue, som beskriver metoden med discovery.meethue. Hvis det er tilfældet, antager jeg, at der foretages den del kald til discovery.meethue, når jeg arbejder med IHC-Captain og mit problem skyldes de fejlede kald til discovery.meethue. PS: Kan du uddybe hvad du mener med: "Kopier den og sæt den ind i din browser" og hvad formålet skulle være?? IP-addresserne på mine HUE Bridges kan pinges, og jeg kan styre HUE bridge'ne med https://<bridge ip address>/debug/clip.html så de er der:-) Med venlig hilsen Steen Vemmelund

Hej Roder pt. med et IHC Controler - IHC Captain - Philips HUE setup, der er "faldet fra hinanden". Jeg har store udfordringer med at få IHC Captain til at hente outputmoduiler for Philips HUE. Jeg har observeret at der er en 1:1 sammenhæng imellem https://discovery.meethue.com/ og dette links's evne til at returnere ip-addresser fopr mine HUE Bridges. Har googlet en del på "discovery.meethue.com" "This page isn’t working" og har fået opfattelsen af, at link'et er overbelastet og Philips anbefaler brug af nDNS til at finde HUE enheder istedet for discovery. Jeg tænker på, om der er en mulighed for, manuelt at tilrette en konfigurationsfil i IHC Captain, så der ikke skal søges efter HUE enheder. Med venlig hilsen Steen Vemmelund

Jeg tager en kig i loggen, hvis der sker igen. Det "mærkelige" var, at forbindelsen ikke var helt væk! Min Funktionsblok "1.5.05 HUE Kip fade op-ned og Sceneskift med PIR kontrol og Blokering" har en "Timer for efterløb" indstiling, som vises i IHC Captain Denne timer blev aktiveret med nedtælling fra initialværd og nedtællingen blev vist ganske fint i IHC Captain. Problemer var bare, at det flag "Tænd/Sluk Hue" ikke skiftede status i IHC Captain, selvom flaget skiftede status i LK IHC ServiceView. Men som sagt ved at stoppe IHC IHC Captain og starte den igen Fungerede det igen.

Hej Mikkel Super – fik ikke lige set din update, men jeg brugte ”ventetiden” til nørde lidet med arberg’s ide om at køre IHC Captain i en Docker container. Jeg har fået lavet en Docker pakke, som jeg, på foreventet efterbevilling, har lagt på https://hub.docker.com/ under sbv1307/docker-ihccaptain. Efter at være blevet inspireret af Docker fra en TelsaMate docker installation, fik jeg den Ide, at man måske kunne køre to IHC Captain Docker containere på en Raspberry Pi, så jeg kunne arbejde med begge mine ICH Controllere fra samme Raspberry Pi. Med arberg som inspirations kilde, har jeg fået lavet en Docker pakke, som installerer to Docker containere, som hver kører IHC Captain, på én Raspberry Pi. Herfra kan jeg så integrere min Philips HUE installation som har lyskilder tilknyttet begge IHC Controllere. Indtil videre ser det ud til at fungere nogenlunde. Jeg har dog observeret, at den ene IHC Captain instans har ”tabt forbindelsen” til sin IHC Controller. Problemet kunne dog løses ved at logge ind på IHC Captain. Stoppe overvågningen at IHC Controlleren og state den igen. Er der andre der mon har oplevet noget ligenende? Jeg har gjort mit bedste for at dokumentere, det har har lavt, og håber det kan have interesse. PS: Din seneste opdatering er taget i brug. Jeg har lavet nogle funktionsblokke til kontrollering af Philips HUE via IHC Captain, som jeg har lagt her: https://drive.google.com/drive/folders/1JKoU0NDU9Zz0jFJ-ZwQy9xcX9v6rhnhh?usp=sharing Med venlig hilsen Steen Vemmelund

Tusind tak for det hurtige svar. Rart at vide, at fejlen erkendt, så er der jo håb forude:-). Jeg antaget, at jeg "bare" skal være opmærksom, når der kommer en opdatering. Med venlig hilsen Steen Vemmelund

Problem: Jeg kan ikke få reglen til at fungere, hvis jeg ændre værdien for "Hvis input værdien er" fra ”forsekellig fra...” til ”identisk med...” Baggrund: Phillips Hue styring, som beskrevet i Manualen, fungerer som forventet. Reglerne aktiveres, når de tilhørende værdier ændres. De to af reglerne bruger definitionen ”Hvis input værdien er” ”forskellig fra..” Ændre jeg definitionen til ”Hvis input værdien er” ”identisk med…”, havde jeg forventet, at reglen blev aktiveret, når værdien skifter til 0 (som er værdien, der er indtastet i feltet ”brugerdefineret"). Forskellige regler med ”Hvis input værdien er” ”forskellig fra..”, hvor værdien er sat til forskellige værdier (f.eks. 1,2,5,9) fungerer fint, men lige netop ”Hvis input værdien er” ”identisk med…” kan jeg ikke få til at fungere – Hvad har jeg overset? Om installationen: IHC Captain version 1.52 installeret flg. SD Kort installation, på Raspberry Pi 3 Model B Rev 1.2. IHC Control 3.0 Med venlig hilsen Steen Vemmelund

.

Jeg har lidt erfaring med Windows 10 i kombination med Visual 1 forbundet med USB til Serial (RS 232) adabter fra min tidligere installation. 1 - Jeg reindre ikke a have haft problemer med at installere visual 1 softwaren på PC 2 - Windows 10 har dog den ”feature” at der kan tildele COM port numre højere en 4, hvor controlleren kun supporterer COM 1 – COM 4. Hvilket jeg ofte oplevede ved tilslutning af en USB til Serial konverter. Løsning: Under Device Manager → Universal Serial Bus contgrollers → ”den USB port hvor konverteren er tilsluttet”, kan COM port nummeret ændres. PS: Kan selvfølgelig ikke vælges til en COM port der anvendes i forvejen. 3 – Visual 1 (of fo den sags skyld, også Visual 3 ) understøtter ikke ”Power management” på USB porten. Dette kan løses med samme metode som ved ændring af COM port nummer: Under Device Manager → Universal Serial Bus contgrollers → ”den USB port hvor konverteren er tilsluttet” er det et Power faneblad.