Kandersen

Det er helt okay. Men man kunne nok have guidet dig igennem forudsat du har Service viewer. Næste gang (som forhåbentlig aldrig sker), så prøver vi det først

Jf. en ande lign sag, så må du meget gerne melde ud, hvad resultatet blev af dette:

Vil ikke? Hvis det er almen forbrugerkøb, så har du 2 års reklamationsret, hvad enten sælger vil det eller ej.. Sådan som du forklarer det, så kan jeg ikke se du har gjort noget galt. Kan controllere ikke håndtere det, (hvilket det efterhånden tyder på V3 controlleren ikke kan), så er der tale om en mangel. Denne mangel skal udbedres af sælger, ellers kan du vælg at hæve købet. Vil sælger heller ikke det, så er der desværre kun een vej, og det er via forbrugerklagenævnet. Samtidig vil jeg gerne slå et slag for, at sælger som disse bør nævnes ved navn i disse tilfælde. Der er ingen grund til at andre forbrugeren ramler ind i lign problemer.

Hmm det er jo en simpel input.. Det burde have været fanget med brug af Service View meget hurtigt.

Det er samme måde openhab cloud virker på. Det er en rigtig god metode, fordi nærmest alle kan være med. Mht Google Home - Det er godt hvis du kan. Det er rigtig godt hvis du kan, og det virker stabilt. Men forvent lidt sure miner, hvis det er ustabilt. Udover at det er irriterende, når fx openhab ikke kan snakke sammen med Google Home, så er det enormt frustrerende, at der er meget lidt man kan lave fejlsøgning som slut brugeren. Faktisk kan brugerne slet ikke vide, om det er openhab (eller IHC Captain, når det kommer) eller om det er Google der fu*** op i det. Et af mine kommende projekter, det går faktisk på at gøre mig uafhængig af openhab cloud i forbindelse med Google Home. Det funger ellers ret godt for tiden. Men der er lige så meget princip i det for mig, at jeg helst ikke vil være afhængig af det. Det er også svært at stille krav, når det er en gratis service opstillet af folk der bruger deres fritid på det. Så jeg har skam forståelse for det. Så, så længe det fungere med openhab, så kan jeg stille og roligt sidde og nørde mig frem til, at gøre mig uafhængig Btw. rygterne går på, at Google selv vil lægge mere "Assistent" over til forbrugeren, så det også virker offline. Det bliver enormt spændende, når/hvis det sker.

Det er også rigtig ærgerlig. Det sker desværre, fordi vi bruger en binding som ikke er officielt udgivet, (eller dvs i dit tilfælde er det faktisk, fordi den er med i openhab 2.5M2). Forvirringen bliver også større, fordi der findes mangle eksempler med fx IP og cfg fil. Og hvis læseren ikke lige er obs på, at det måske er en nyere version man sidder og roder med. Ja, så bliver der ballande. Her er loggen den bedste hjælp. Jeg har ikke tal på, hvor mange gange jeg er kommet til at skrive noget forkert. Jeg har nærmest altid loggen stående åben, når jeg roder med noget, uanset om det er items, sitemaps eller configuration, simpelthen fordi den fortæller mig, når jeg skriver noget forkert. Problemet med loggen er, at det er ikke altid det er lige oplagt, hvad en fejl er. Hvis ikke man ved hvad man skal se efter, eller hvad der skrives, så er man oftest ude i store problemer. Det bedste metode her, det er at gå tilbage, gøre det om man gjorde (evt fjerne det) og så gemme filen på ny. Så bør fejlen være væk, og man kan prøve igen. Det er meget underligt du oplever dette. Jeg vil næsten vove den påstå, at lige præcis IHC bindingen er en af de mest stabile bindinger jeg har kørende. Det virker hver gang og reagere promte. Det er også den mest vigtigste binding jeg bruger, fordi IHC installationen er mit primære opsæt. Man kan ændre log indstillinger til TRACE eller DEBUG. Så får man alt i bindingen at vide. Men man skal være forberedt på, at man bliver tæppe bombet med informationer. Så oftest kan man ikke nå at følge med, hvis man som jeg bruger tail loggen i et åbent vindue. Så må man ty til den "rigtige" logfil. Det er sket at jeg har måtte gøre det, specielt i forbindelse med Zigbee. Zigbee er en af de ting jeg DEBUG logger konstant til sin egen fil, fordi det er hammerende ustabilt, og jeg hjælper udvikleren med at fejlesøge. Det er allermest erfaringen som er problemet. Når først man har rodet lidt med det (svært ord at definere hvad 'lidt' er), så ved man hvor man skal være vågen. Uden at prale, så vil jeg tro jeg kan have en Rpi 3B+ (med SSD disk) oppe og køre med fuld opdateret openhab, IHC bindingen og de første 3-4 channels, items og sitemap inde for ca 30-45 minutter. Og det meste af tiden vil være gået med at få openhab opdateret og kørende, og så lave de tekst linjer der skal til i things, items og sitemap. Har man filerne fra en tidligere installation, så er bare en copy filerne ind i folerne. Så er man flyvende. Jeg ville ønske der var en nem måde at lave en guide på. Jeg er faktisk også i gang. Men for pokker hvor er det tidskrævende.. Og så var min plan jeg ville lave videoer. Men det blev også en udfordring for mig.

Kan du fortælle hvad der var galt? Det er mere så andre ikke ender i samme situation!

Min påstand er, at langt de fleste kan gøre det. Det kræver en lyst og en vilje til at ville lære det. Lidt ala at tage et kørekort. Når man har fundet ud af det grundlæggende, så er det faktisk uhyre nemt. Men af det afhænger dog af, hvad det er man vil. Personligt har jeg selv gabt over rigtig meget med openhab (og IHC for den sags skyld). Og jeg har fået massive "øretæver" og sandsynligvis også blevet en del mere gråhåret. Og jeg har stadigvæk langt igen, hvis jeg skal nå alt IHC Captain er på mange måder et færdigt produkt, som kan det som det kan, og thats it, (selvom det faktisk også kan en hel del, hvis man er lidt viden om http/json osv). Men så er man netop igen ovre i, at man skal lære noget først. Som en egentlig UI til IHC installationen, der er den uden tvivl uhyre effektiv og simpel, så alle kan være med. Og det er utrolig godt at Mikkel laver det, fordi det på mange måder betyder, at IHC brugere ikke pine død er tvunget til at købe LK´s vanvittig dyre app, for noget så simpelt.

Openhab og IHC Captain er ikke samlignlige på nogen måde.

HMPRF!! Blot for god ordens skyld og for at eliminere evt årsager. Har du tømt cache og tmp mapperne på din Rpi? De ligger i /var/lib/openhab2/ Stop Openhab inden du tømmer dem: sudo systemctl stop openhab2.service Derefter sletter du alt i /var/lib/openhab2/cache og i /var/lib/openhab2/tmp Og så rebooter du med: sudo shutdown -r now

@bozidar Det er lidt meget underligt med dine problemer. Jeg fatter ikke du i loggen ser hele kanalen ændre status. Du burde kun se items navnet.. Jeg lurede lidt på, om der evt er en fejl (skjulte karaktere) i dine filer, for jeg kan ikke se der skulle være noget galt.. Hvis du kan lave et screendump af dine kanaler for den kanal du arbejder med i PaperUI, så vil jeg prøve at genskabe dine filer her ud fra de data du har. Det jeg er interesseret i, det er at se channel på den du forsøger lave en item til, ligesom jeg viste på mit billede fra paperUI i går. Ahh vent lige.. Prøv lige at ændre din items til denne linje: Switch Stue_Lys "Spots i stuen [%s]" <light> ["Ligthing"] {channel ="ihc:controller:elko:output331648091", autoupdate="false" } Se om det går bedre fra sitemap.

Det er fordi du kun ser "halvdelen af historien". Jeg brugere ikke de automatiske channels.. Jeg laver derimod alle channels selv i .things filen.. (den kan du da godt få lov at se, hvis du kan rumme det :-) ). Årsagen til at jeg gør det, er fordi at jeg derved har fuld kontrol over det, og ikke er låst fast til de automtiske (default) parametre som Pauli har sat det til. Fx bruger jeg meget pulswidth i mine channels til trykkene. Nogle på 300ms andre lidt hurtigere. Default er der ikke pulswidth i autochannels. Dernæst så sætter jeg alle kanaler som kun skal være readonly til readonly. Default er alle kanaler ReadWrite. Og ikke mindst, så kan jeg også sætte default tænd værdien til wireless dimmerne. Fx når jeg beder Google Home om at tænde lyset i køkkenet, så har jeg sat dimmeren til at tænde på 50%. Default er 100%. Så der er visse fordele ved at lave det hele manuelt. Men det tager også ufattelig lang tid at komme dem alle igennem.. Her er channel for det item du undrede dig over: Type switch :stuen_m1 "Stuen M1 trigger" [ resourceId=181009, direction="WriteOnly", pulseWidth=300 ] Bemærk det der står efter den første : (stuen_m1). Det er nu navnet på den kanal, som jeg derefter bruger i min .items fil, som du hæftede dig ved. Hvis jeg havde brugt auto channels som du gør, så ville mit items have lignet din. Men det bliver bedre endnu.. Ved at tage outputtet på den IHC Funktionsblok som man aktivere på input samtidig, så kan man få knappen i OH til at følge med uanset om du styre det fra OH, IHC eller andet.. Det kræver man laver en ekstra channel til outputtet: Så ser mine channels sådan her ud (for M1 i stuen): Type switch :stuen_m1 "Stuen M1 trigger" [ resourceId=181009, direction="WriteOnly", pulseWidth=300 ] Type switch :stuen_m1_state "Stuen M1 lys" [ resourceId=27227, direction="ReadOnly" ] Og så samler man det i een items, som kommer til at se således ud: Switch stue_sov_OEV "Stue M1 [%s]" <light> (vLys) ["Lighting"] { channel="ihc:controller:elko:stuen_m1", channel="ihc:controller:elko:stuen_m1_state", autoupdate="false" } Bemærk jeg nu bruger begge kanaler. Den ene til at trigge med, og den anden til at aflæse status. Begge er linket til samme item. Her er to klip fra Visual, så du kan se hvor jeg henter ResourceIDérne fra:

It makes better sense, when you get the controller online, and you get to play with things, items and sitemaps. Did you get the controller online?

Ahh you´re right Pauli.. He´s using the latest in 2.5M2..

har du tømt cache og tmp mapperne?

Helt iorden. råb endelig op hvad det bliver ved med at drille.. Det her burde altså bare virke.. Det er "alt det andet" som er det besværlige :-)

Kommer controlleren online? Fjern evt også den anden controller og start forfra (genstart OH først, evt clear cache og tmp).

Det er selve controlleren.. Du har 2 controlleren nu, som det vises her. Den ene fejler, den anden er online.. Men den hedder tilgengæld ihc_controller:37f1c4d0 Det sidste tal ligner noget openhab selv har fundet på.. Dvs du har en controller inde, som openhab selv har fundet.. (troede jeg ikke den kunne, men jeg bruger det jo heller ikke selv på den måde). Den som er i din .things fil, den fejler. Prøv at slet den der ihc:controller:37f1c4d0. Den anden skulle genrne komme online medmindre din .things fil stadigvæk fejler (husk at hold øje med loggen).

Tag evt et screendump af paperUI hvor den kanal er du vil linke.

Tag evt et screendump af paperUI hvor den kanal er du vil linke.

Yep, fjern bare det sidste igen fra din .thngs fil (forstår ikke hvorfor den fejler for det, for det plejer den ikke)... Dit problem ligger i din items file under { channel="ihc:controller:elko:xxxx } Du skal linket til den resourceid som vises i din PaperUI ud fra den kanal du vil bruge, (se billede i forrige indlæg).

Hov.. Din resourceid er lidt underlig (kiggede lige i min egen for de automatiske kanaler.. Se fx en kanal her hos mig: Bemærk de hvor den røde oval er.. Se ihc:controller:elko:output18779 Det er det resourceid der skal bruges i items filen.. Altså { channel="ihc:controller:elko:output18779" } Din resourceid i din .items fil ser meget anderledes ud, for der er ekstra tal.. Hvor det kommer fra, det må guderne vide. Men det skal ikke være der.

Det burde fremgå af loggen så. Hold øje med loggen, når du retter noget i .things filen.

Der var tydelige fejl før, og det burde slet ikke virke. Men der er noget helt galt nu, som jeg ikke helt forstår. Dit setup er dog anderledes end mig, fordi jeg bruger manuelle kanaler. Men det burde ikke have betydning i det her tilfælde. Jeg formoder det resourceid du bruger i din items ( 37f1c4d0:output331648091 ) at det har du taget under kanalen i PaperUI, ikk? Lidt ændringer: Prøv lige den her i din .things fil: (bemærk jeg har sat noget ekstra på). ihc:controller:elko [ ip="192.168.0.3:443", username="admin", password="password", timeout=8000, loadProjectFile=true, createChannelsAutomatically=true ] { Channels: } Og den her i din .items fil: (har sat autoupdate="false" ind tilsidst). Switch Stue_Lys "Spots i stuen [%s]" <light> ["Ligthing"] {channel ="ihc:controller:elko:37f1c4d0:output331648091", autoupdate="false" }

Øhh.. itemstatechange er item der skifter, men den viser kanalen. Det er da helt tosset. Det her er fx når jeg tænder og slukker lyset på mit hjemme kontor: 2019-08-14 23:02:59.701 [vent.ItemStateChangedEvent] - kontor changed from ON to OFF 2019-08-14 23:03:01.944 [vent.ItemStateChangedEvent] - kontor changed from OFF to ON Bemærk, kontor er item navnet.. Ikke kanalen.. Gider du lige poste hele din .things fil her.