Ole

Jeg forholdt mig faktisk ikke til wireless dæmperen, selv om det selvfølgelig fremgår af Thomas´s indlæg, men blot til det faktum at 2 tændinger på samme udgang (Løsning 1) giver langt færre muligheder i fremtiden.
I min verden findes der kun én lysdæmper,  og den er pt wireless. Når den nye DIN-skinne monterede LED dimmer kommer, bliver det den. Alt andet giver ikke mening i et nybyggeri.

Så længe der ikke er 100% vished om kvaliteten ville jeg nok holde hesten lidt. Årsagen til crashet er der kun gisninger om endnu, og LK har mig bekendt ikke været fremme med en melding.
Hvis en kontroller skal byttes pga. en genstart eller en FW opgradering taget fra deres egen hjemmeside, er det ikke ordentligt testet før frigivelsen til salg. Blot min mening.
 

Ikke et spørgsmål men info vedr ombytning af Hw7.1 controller
 
Min controller har været ustabil siden jeg lagde fw 3.3.21. Det viste sig ved at hver anden/tredie uge stoppede den med at reagere på input. Hver gang har jeg taget strømmen i et minuts tid og den har så bootet op igen og kørt videre.
Men i mandags prøvede jeg i stedet at trykke genstart. Denne gang kom den ikke op igen, men stod og rebootede konstant.
Jeg kunne kun få kontakt til controlleren via firmware loaderen igennem ethernet, ikke usb, ikke visual, ikke administrator/serviceview.
Prøvede nogen gange at tage strømmen og trykke på den røde reset knap, men det hjalp intet.
Fandt en reset firmware i download sektionen og lagde den på, og så kunne jeg ikke længere tilgå den via netværk heller, hvilket giver mening hvis netværks indstillingerne er blevet overskrevet. Dvs ingen forbindelse overhovedet. Kunne se på OK led`en at den stadig kørte en kontinuerlig reboot.
Skrev til Greenline og de ombyttede med det samme, og modtog så en ny i dag. Den nye havde fw 3.3.7 installeret så den er nok ikke helt frisk fra samlebåndet.
Jeg var spændt på at bruge gendan fra SD kort funktionen. Det fungerede rigtig fint og program samt alle wireless enheder kom frem, linket til controlleren.
Fik konfigureret administrator mht til brugere og netværk og til sidst installeret fw 3.3.18, i stedet for .21. Den har i hvert fald for mig kørt upåklageligt tidligere.
Trods alt positivt at man kan komme i gang igen inden for 15-20 minutter, uden at skulle kæmpe med linkning af wireless enheder eller lede efter den backup man måske har glemt at lave.

Hej Ulrich,
Kan du ikke med en mindre modificering benytte en af @Lars Jacobsen fine watt meter funktionsblokke?
Hilsner Ole

Det virkede i øvrigt.
/Claus

Har du ikke en magnetventil med ind over, der lukker 10 liter vand ud i afløbet fra tid til anden, når familien ikke er hjemme!?
 

Der er flere, som har haft udfordringer med opgradering af en hw7 controller til firmware 03.03.18. Derfor besluttede jeg at være lidt forsigtig og gjorde følgende:
Fandt en ældre ledig bærbar PC, som jeg installerede Ubuntu linux distribution på. Det var faktisk overraskende nemt med simple peg og klik. Tog SD kortet ud af min hw7 controller og kopierede alle filer til PC'en. Der var ingen 'hidden' filer. Formaterede et gammelt 64Gb SD kort i ext3 format, som også er formatet, der bruges i LKs sd kort. Herefter kopierede jeg alle filer til det nye kort og satte det i controlleren. Controlleren blev genstartet og startede fejlfrit op med mit eget SD kort - se skærmkopi. Herefter opgradede jeg firmware til 03.03.18 på mit kort og det fungerede fejlfrit. Mit eget kort brugt til den første test blev atter fjernet og erstattet af det oprindelig kort fra LK, hvor jeg ligeledes foretog firmware opgradering uden fejl. Så det er muligt at have sit eget SD kort dels til aftestning af ny firmware før endelig installation, dels som backup, hvis det originale LK kort skulle blive defekt.
 

Edit: Det er efterfølgende gået op for mig, at man ikke kan konkludere, at sd kortet indeholder firmwaren. Jeg kontrollerede ikke firmware nr før opgradering nr. 2. Der er kun én fil på kortet, som hedder "stored". Den fylder i mit tilfælde kun 194 KB, hvilket nok ikke kan rumme firmwaren - selv i compileret format.

Forholder det sig ikke ofte sådan, at vi er bedre til at give til kende, hvis der er noget vi er mindre tilfredse med, end noget vi er godt tilfredse med - selv om jeg prøver at være opmærksom på det, er jeg i hvert fald selv indrettet sådan. Min pointe er at vi nok hører om flere negative oplevelser en gode, med baggrund i den antagelse.
Indrømmet, jeg kunne også ønske mig wireless forbedringer i relation til IHC, men stabiliteten er absolut på et niveau, hvor jeg ikke finder behov for at spekulere i alternativ.
/Ole

Some reason Google translator translate pretty "bad" english, so it's pretty hard to fully understand what you try to reach on your example.
Anyhow, following configuration is read only from openHAB perpective, meaning that only timer value change in IHC is updated to openHAB item.
Number U_TimerVand                        "Timerværdi for vanding [%.0f]"                            <time>            {ihc="<0x1102410"} So if you change the U_TimerVand item value, it will not be updated to IHC. When every timer value is changed in IHC side (timer is running or you change it via service view), value is updated to openHAB item.
Timers are in millisecond resolution in IHC, so I guess that, if timer is running, you will get a lot of updates. Maybe not every millisecond, but very often. 
So most probably it's not wise to sync timer value between openHAB and IHC. If you just want to change the timer value from openHAB to IHC, you could make it write only (>). If you want to know when timer is expired (counted to 0), your most probably should change the IHC code so that when timer is expired some kind of flag is set, which change is then syncronized to openHAB.
 
Syntax explanation:
Syncronization in both directions (IHC <-> openHAB):
Number U_TimerVand   "Timerværdi for vanding [%.0f]"   <time>  {ihc="0x1102410"} Read only (IHC -> openHAB):
Number U_TimerVand   "Timerværdi for vanding [%.0f]"   <time>  {ihc="<0x1102410"} Write only (openHAB -> IHC):
Number U_TimerVand   "Timerværdi for vanding [%.0f]"   <time>  {ihc=">0x1102410"}  

I have 63 switches in my ihc.items file, and they are all using this feature. Besides that I have a few contacts and numbers, and they have mainly readonly definition. One number for the level in my ventilation system has ReadWrite definition.
The real use case is that this feature provide a very simple and reliable method of having correct status in openHAB regardless of whether a change was initiated by openHAB UI or a physical input push button attached to IHC. In openHAB it can be quite cumbersome to detect the origin of a change, and suppress additional activities if it was initiated by a physical button, because then everything is done. Before I discovered you smart binding options, I tried a variety of rules including wait, circular refences and sometimes also unintended endless loops inside openHAB. I wrote a posting about this, and it can be read on here (use Chrome to have English translation).
With this feature I can map my entire IHC installation quite simple without the need for rules. Rules are only needed, when I would like a special functionality. It is important for me that IHC is the master and holds all relevant logic and status. There are several reasons for this and one is that the installations in the house must always be working without being depending on 3rd party software such as openHAB.

@meinert for mit vedkommende er det et ønske om bedre integration af ventilationsanlægget i det samlede setup. Det primære ønske er muligheden for at styre hastigheden og ønsket indblæsnings temperatur, samt se filter alarmen – gerne i antal dage tilbage. (jeg kører med fast frekvens af filterservice). Sekundært muligheden for at stille uret ved sommer- / vintertids skift – men mindre relevant hvis muligheden for at (over)styre hastighed og ønsket indblæsningstemperatur er til stede. Jeg ønsker at styringen skal ske fra OpenHAB af, i det jeg her har adgang til mine Netatmo sensore, og IHC installationen. Jeg har ikke noget ønske om en separat app – tvært i mod. Selvom OpenHAB app’en næppe er det mest lækre man har set, så synes jeg styrken er at man kan samle betjeningen her, så jeg ikke skal åbne Netatmo app’en for at se klima informationer, Hue app’en for at styre lyset, PowerView app’en for at styre gardiner, og så videre.
 

Vil lige dele en ting med jer.
Er med til at bygge et nyt udstillings hus i Ballerup. På denne udstykning kommer der til at ligge nye huse fra forskellige typehuse firmaer.
Vi har fået sponsoreret IHC til det ene af vores huse. Så lidt gør LK da for at eksponere deres produkter.
Håber så bare på at der er flere af husene her, som har fået samme tur. Så det medvirker til at flere for øjnene op for IHC og det på den lange bane, at LK bruger flere ressourcer på udviklingen/integrering af nye produkter.
Kan godt være det bare er ønske tænkning :-)
Kristoffer

Jeg har endnu ikke oplevet impulsive genstarter - alt er foreløbig kørt stabilt inkl. openhab og Homekit.
Dog ser der ud til, at æ, ø og å ikke kan bruges i beskeder i SMS modemet. Jeg har meldt det til LK, men ved ikke, om de gør noget ved det. Hvis der er andre, som kan påvirke LK, vil det være fint. Det skulle være nemt at efterprøve.
Der er med sikkerhed ikke brug for en KeepAlive rule eller forøget timeout interval til openhab som i de seneste versioner af firmware 2.x

Nu har jeg styr på det - OpenHab 2.1 og IHC fungere perfekt sammen. Jeg har endda koblet Amazon's Alexa til OpenHab, så nu kan jeg faktisk "tale" til min IHC gennem OpenHab. F.eks "Aleax - turn on the kitchen light" også tænder det IHC kontrolleret lys i køkkenet.
Jeg har hentet meget inspiration hos https://www.mksmarthouse.com/ 

Undskyld for at lege politi/bussemand, men nu sker det igen - hijack af tråden.
Derfor (PHL og i andre) opret en ny tråd om emnet, eller find en eksisterende og spørg videre i den. Det er møgforvirende for brugere at man skal finde kabeldokumentations oplysninger som er et HW / installations relateret emne, under OpenHab software.
Kan se Kandesen forsøgte, men Bjarne faldt i 

Så har jeg købt den nye IHC Controller, HW 7.1, hvor man skal bruge Visual 3 til projektet. Jeg tilsluttede den til strøm og netværk, ændrede default ip adresse til en ledig i mit netværk og oprettede samme user+pwd som i min nuværende HW 6.1 controller. Der er ingen input- eller output moduler tilsluttet den nye controller endnu. Dernæst kopierede jeg mit Visual 2 projekt ind i Visual 3, åbnede projektet og sendte det til den nye controller fra Visual 3. 
I OpenHAB ændrede jeg dernæst ip adressen til den nye controller og genstartede OpenHAB. Herefter kan jeg konstatere, at OpenHAB starter fejlfrit op. OpenHAB fungerer - men viser naturligvis 0 grader ved temperaturer m.m. - og jeg kan påvirke input og fb'ere som normalt. Når dette sker, kan jeg konstatere i den nye ServiceView, at status rent faktisk ændres som følge af OpenHAB input. Så alt ser umiddelbart ud til at fungere - vældig fint!
Jeg har endnu ikke indblik i stabilitet på controlleren, eller om det er nødvendigt med en KeepAlive rule som i de sidste versioner af firmware til HW 6.2.

Hej Ole. Du mangler blot at indsætte selve strengværdien i dit item. Altså tilføje "[%s]".
Fx:
String V_MarkiseTilstand "Tilstand for terrasse markise: [%s]" <rollershutter> {ihc="<0x15BC70F"} eller blot:
String V_MarkiseTilstand "[%s]" <rollershutter> {ihc="<0x15BC70F"} Mvh Claus

Jeg ved godt mange af jer siger der er andre alternativer. Men reelt er de jo ikke specielt realistiske. Smart-home systemer er der skam, men vi der har IHC har allerede en integreret del, som disse smart-home systemer ikke fungere skide godt sammen med, (og iøvrigt fungere de ikke indbyrdes skide godt sammen). Så på en eller anden måde bør der ske noget med IHC. Enten en klar udmelding, at systemet udgår, eller at det udvikles i mere moderne retning. At udskifte hele IHC er jo ikke noget man bare lige gør. 
Så som det er, pt er det noget rigtig skidt. Specielt hvis man som mig, gerne vil opgradere controlleren. Jeg har som sådan ikke noget imod at købe en hw 6.2 med viewer i dag, (har en hw. 6.1 uden viewer), men jeg gider heller ikke være til grin og brænde inde med 2 forældede controllere  

Der har tidligere været et indlæg her på siden angående gravering af tangenter. Og en foreslå at man kun købe en graveringsmaskine på eBay. Ville lige dele min erfaring med denne maskine se eventuelt resultat synes faktisk det er ret ok.
http://www.ebay.de/itm/282377709738?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

nå efter mange år... Og mange test, gad jeg ikke ihc "web referance" mere.
jeg har kodet protokollen selv og har en C# class hvis nogle er interesseret.
jeg sidder og arbejder på en raspberry pi3 med touch skærm bygget ind i væggen, og hvor jeg har kodet et UWP program til windows 10 IoT.
hvis nogle er interesseret vil jeg gerne dele min souce kode.

Det har jeg såmænd også. Jeg er glad for min installation og ærgrer mig ikke over alle de timer jeg har brugt med IHC (og dette skønne site).
Det er heller ikke sådan at jeg fraråder folk at installere, udtaler mig negativt eller lader min evt. personlige galde flyde ud på Internettet Jeg prøver bare at forholde mig sobert til fakta.
Jeg håber altså også stadig at de (LK/Schneider) tager sig sammen, men med det vi har set indtil nu -specielt med lukketheden omkring JAVA problemstillingen, så er det altså svært at bevarer optimismen, blot fordi der nu er blevet ansat en ny studenter medhjælper i markedføringsafdelingen der mener Facebook er det evigt saliggørende medie.

Hej.
 
Jeg har brugt regnvejrsdagene til at lege lidt med IHC appen på ipad, og er kommet frem til følgende resultat
 
Er selv ret godt tilfreds, har et par enkelte små ændringer til min næste version.
 

 

 

 

 

 

 

 

 

Jeg sidder i Krakow Polen og har lige konstateret at det er billigst for mig at vi bliver her resten af året, (pt 36 grader).
Se hvor meget strøm jeg sparer ved ikke at være hjemme
Vi tog afsted fredag aften.