Kandersen

Det tror jeg vil give langt større problemer, fordi meget dataudstyr til mobil data endnu ikke supportere 5G. Og 3G er alt for ringe i forhold til produktet som man har købt. Specielt for dem som har købt mobil data abonnement.

Ahh okay, så er jeg med

Jf ovenstående log (venstre side) som er fra ServiceView, så kan du se, at det er ikke helt det der sker i IHC controlleren. Faktisk har jeg registreret "tavshed" i IHC controlleren i 24 minutter, fra 15:35.50 24,8°C til 15.59.35 -1,2°C. De efterfølgende målinger ligger bestemt heller ikke i nærheden af de 5.5 sekunder. Eller så forstår jeg ikke hvad du mener. Ovenstående log er logget direkte på produktet i venstre side i Serviceview. Altså ikke en log som Openhab har nogen indflydelse på.

Det kan jeg godt tvivle lidt på. Når en mobil i dag har Edge forbindelse, så er det dælme ikke meget data der virker. Det er bla det som 5G skal ændre på, som vistnok er 700mhz og får en temmelig stor udbredelse. Men der er ikke plads til 2G, 3G, 4G og 5G samtidig. At fjerne 3G eller 4G før 2G, det giver meget lidt mening.

Nå gider ikke rode med de logfiler mere. Tror ikke Openhab har et problem med at modtage fra controlleren. Derimod har openhab et problem med tail loggen. Se disse.. Bemærke hvad openhab har registreret imellem 2018-06-16 15:35:50.453 og 2018-06-16 16:11:38.482. Openhab har, uden at vise det i loggen, registreret føleren har skiftet fra 24.80 til 24.70: 2018.06.16 16:19:00 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,4°C 2018-06-16 16:19:00.258 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.50 to 24.40 2018.06.16 16:16:37 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,5°C 2018-06-16 16:16:36.700 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.60 to 24.50 2018.06.16 16:12:01 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,6°C 2018-06-16 16:12:00.582 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.70 to 24.60 2018.06.16 16:11:55 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,7°C 2018-06-16 16:11:55.085 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.60 to 24.70 2018.06.16 16:11:39 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,6°C 2018-06-16 16:11:38.482 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.70 to 24.60 2018.06.16 15:59:41 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,7°C 2018.06.16 15:59:35 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = -1,2°C 2018.06.16 15:35:50 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,8°C 2018-06-16 15:35:50.453 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.70 to 24.80

Hov.. Glemte lige pointen med ovenstående.. Det betyder selvfølgelig, at jeg ikke kan regne 100% med OpenHab, når den kan misse 2 målinger.. Det borer jeg lidt mere i. Men det finurlige er, at det er tilsyneladende efter at sensoren har været tavs i lang tid, at Openhab ikke rammer de første ændringer igen.. Jeg skal lige være helt sikker.. Sensoren sender IKKE en opdatering, hvis der ikke har været registreret en ændring. Er det korrekt? Samme værelse har jeg nemlig en periode på over 2 timer, hvor der ingen registreringer været i går. Jvf ovenstående kan jeg jo selvfølgelig ikke vide, om det er sensoreren, IHC controlleren eller Openhab.. Openhab har i hvertfald et problem, kan jeg se.

@Klaus Larsen Jeg sidder her og følger logfil fra openhab (tail log) og serviceview samtidig. Indtil nu så kan jeg sige med sikkerhed, at ud af 8 opdateringer fra en sensor, så er det kun 6 som OpenHab har registreret. Så det er selvfølgelig et problem. Det skal lige siges, at ovenstående måling måtte jeg "aktivere" manuelt ved at gå ind i rummet og puste direkte på sensoren, fordi den ikke havde sendt nogen opdatering i næsten 20 minutter. Lige så snart jeg pustede, så loggede serviceview ændringer, og openhab begyndte at registere også. Men openhab missede de 2 første ændringer. Se herunder. 2018.06.16 14:12:16 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,9°C 2018-06-16 14:12:16.170 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.80 to 24.90 2018.06.16 14:12:11 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,8°C 2018-06-16 14:12:10.716 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.90 to 24.80 2018.06.16 14:12:05 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,9°C 2018-06-16 14:12:05.304 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.80 to 24.90 2018.06.16 14:11:16 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,8°C 2018-06-16 14:11:15.520 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.70 to 24.80 2018.06.16 14:10:20 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,7°C 2018-06-16 14:10:20.240 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.60 to 24.70 2018.06.16 14:09:53 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,6°C 2018-06-16 14:09:52.667 [vent.ItemStateChangedEvent] - amanda_Temperature changed from 24.50 to 24.60 2018.06.16 14:09:42 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,5°C 2018.06.16 14:09:36 Lokalt Amanda værelse / Temperatur sensor / Rumtemperatur = 24,7°C

Det må være Grafana som laver det så, for Openhab virker som den skal. Dog synes jeg der er blevet længere imellem opdateringerne fra sensorene, i forhold til hvad det tidligere var.

Nå havde ikke tålmodighed til at vente til weekenden. Det her er jo simpelt at afprøve @Mikkel Skovgaard Ulle har desværre ret. Jeg kan heller ikke få IHC Captain til at sende en mail mere end første gang. Genstarter jeg IHC Captain, så virker det igen. Og det er IKKE mailserveren. Der kommer slet ikke noget som helst igennem til mailserveren, når man forsøger igen efter første gang. Jeg har min egen mailserver, så jeg kan følge med i alt indgående trafik. Der sker nada efter første mail. Jeg testede det med at fast fortrådet tryk.

@Klaus Larsen Jeg er ikke så sikker på, at jeg vil bruge det der D-filter alligevel. Der er noget galt. Jeg oplever i meget lange perioder, at jeg slet ikke modtager en opdatering fra de sensore, som jeg fik sat D-filter på. Her er et billede (Grafana) som viser to sensorer. Det ene (grønne) har D-filter. Den anden (Gul) har ikke. Bemærk perioden hvor der ingen grøn streg er.

Inden jeg går i krig med at knække den her irriterende timeout. Så vil jeg lige høre, hvordan I andre oplever problemet? (husk at fjern evt rules i muligvis har brugt for at undgå problemet). Jeg bruger en IHC controller HW 6.2 med firmware 2.8.4 Her er mine erfaringer: Alle mine IHC switches i Openhab virker fint.. (bruger dem dog relativ sjældent). Alle mine IHC dimmers virker fint. (bruger dem relativ sjældent via OpenHab men opdatering og status fra IHC controlleren til OpenHab virker altid) Alle mine IHC PIR´s virker fint. (virker konstant med foreløbig 6 fortrådet IHC PIR´s) Alarm status/meldinger osv virker altid fra IHC controlleren til Openhab. Alle mine IHC temperature/fugt sensorer virker fint. (virker konstant med 12 Zigza sensore, hvoraf 2 er tempt/fugt) Alle mine IHC temperatur setpoints virker fint. (virker konstant, dog kan Openhab være lidt træg til at opdatere, hvis man skifter/bladre setpunkt hurtigt, men den kommer altid igennem). Når jeg oplever timeout problemet: Jeg har en Z-wave PIR, som jeg, via en simpel rule i OpenHab, har sat til at aktiver en virtuel IHC PIR i IHC controlleren. Denne virtuelle PIR bruger så en almindelige PIR timer funktionsblok. Denne giver praktisk talt altid timeout i OpenHab ca. 8 ud af 10 gange. Og problemet er blevet mærkbart værre fra jeg startede og til nu. (nok de sidste 3-4 måneder). Kort fortalt - Når Z-wave PIR går ON, så sender Openhab kommando ON til den virtuelle PIR i IHC controlleren, som så starter timeren i funktionsblkokken. Mere simpelt kan det ikke gøres. Det giver mig en ide om, at det er IHC controlleren som der sker noget med, når den skal aktivere en timer "udefra" og Openhab ender ud i en timeout. Men det er kun en teori, foreløbig. Det pudsige er, at når den melder timeout på Z-wave PIRén, så kan jeg sagtens tænde lys via OpenHab på en virtuel switch. Den kommando kommer fint igennem til controlleren, selv få sekunder efter den lige har meldt timeout til Z-wave PIRén, og også selvom at den få sekunder efter igen, melder timeout med Z-wave PIRén. Det er her det bliver rigtig kryptisk, for principielt burde der ikke være forskel på om det er en switch, en kontakt, en PIR eller andet. Men noget mystisk sker altså i lige præcis det her tilfælde, som jeg tror ligger i andet end selve kommunikationen mellem IHC controlleren og OpenHab. Jeg har flere ting jeg skal have testet/undersøgt i denne forbindelse. 1. Fjerne timeren i IHC controlleren, og tjek at Z-wave PIR altid kan trække et normalt produkt. Fx et output til en lampe, men kunne også bare være en virtuel PIR uden FB. <-- Simpel test. 2. Hvad sker der hvis jeg i stedet for at bruge Z-wave PIR, bruger en manuel virtuel switch i OpenHab, til at starte en timer i IHC Controlleren. <-- Simpel test. 3. Hvad laver IHC controlleren ellers, når problemet opstår. <-- Ikke så simpel 4. Deaktivere alt andet som snakker sammen med IHC controlleren "udefra" (fx min anden Rpi som kører med IHC Captain). 5. Have sat mig mere ind i OpenHab´s logfunktion, så jeg kan adskille IHC delen fra resten og lave en debug log. Det er muligt, men det er dælme også langhåret med OpenHabs log system. Og jeg ved ikke præcist, hvad en debug log vil vise mig. 6. Stress testet IHC controlleren med mange ting der bombardere den på een gang fra Openhab <-- ved ikke lige nu hvordan jeg gør det Er der nogen som har andre forslag, ideer, og rigtig gerne jeres erfaringer med det her problem.

Det burde den måske. Men den gjorde det ikke forleden aften, 100% sikkert.. Eller rettere, det er muligt den gjorde, men jeg kunne ikke slukke Hue lyset på IHC tryk bagefter Jeg har nogle ændringer jeg skal lave i programmet i den nærmeste fremtid, så holder jeg øje med den..

Hvis jeg får tid i weekenden, så skal jeg prøve at sætte det op hos mig. Har egen mailserver, så jeg ved præcis hvad der sker.

Hej @Mikkel Skovgaard I forgårs skulle jeg lave nogle ændringer til mit Visual program, som jeg derefter uploadede til controlleren (helt som normalt). Da jeg senere skulle slukke lyset i min stue via IHC tryk, så skete der nada (det er de Hue lamper som er styret via IHC Captain). Jeg troede egentlig det var fordi IHC captain var stoppet, ligesom der tidligere har været et problem med. Jeg var dog på vej i seng på det tidspunkt, så jeg fik først tid til at se på det i går. I går: IHC Captain var IKKE stoppet. Og jeg kunne stadigvæk ikke slukke lyset på IHC tryk. Jeg måtte genstarte IHC Captain, førend jeg igen kunne slukke/tænde lyset i stuen. Bruger selvfølgelig version 1.10.

Jeg kender ikke så meget til home assistant, men jeg formoder ikke det er ret meget anderledes end Openhab. Servodan dimmerne er såvidt jeg husker, principielt det samme som en UNI400/350 dimmer. Med den type dimmer, så er det et problem at få vist "noget" i HA eller OH, fordi der ikke rigtig er en status melding fra dimmeren. Men hvis du i IHC programmet bruger den almindelige FB til fortrådet dimmere, så kan du få vist en status på, om dimmeren er tændt eller slukket. Og det er så det. Det er ihvertfald så langt jeg er kommet med en UNI400 dimmer. Det burde du også kunne i HA.

Hej enig Mikkel. At Lk overhovedet kom med den HW7 controller sidste år, er simpelthen en skandale, når simple mangler som fx notifikationer ikke er med. Vi kan krydse fingre for, at 2G snart forsvinder. Det burde lægge et massivt pres på LK.

@Klaus Larsen Jeg har indsat din D-filter på 3 af temperatursensorene i går, og det lader til at det ihvertfald har en indflydelse på de "spikes" jeg så før. Nu lader jeg det lige køre i nogle dage, og hvis de forsvinder, så bliver de resterne sensorer også ændret.

Det kunne være interessant at få en LK reaktion på dette. Ikke at jeg tror det kommer til at ske. Derudover kunne det også være interessant at lave samme test på nyeste fw, (2.8.4) og evt på en HW 7 controller. Bekymrende er det dog, under alle omstændigheder.

Der er ikke decideret afsat en dato for sluk af 2G. Men der er for mig at se ingen tvivl om, at når 5G begynder at blive seriøst, så kommer ønsket fra teleselskaberne om, at GSM nettet nedlægges. 5G testes i øjeblik med temmelig positive resultater. Så min vurdering er, at vi i år eller 2019 vil se dette ønske blive effektueret eller i det mindste med en fastsat dato.

Jeg kender ikke Zero, men det lyder som om en Rpi3 er sagen Jeg har i øvrigt fået min Rpi over og køre på en SSD, (så er det slut med SD kort). Nu skal jeg i gang med Indflux og Grafana. Men jeg skal først lige studere det der Grafana noget mere, for jeg bruger primært BasicUI. Og jeg har en mistanke om, at det ikke helt er meget bedre, rent visuelt.

Det tror jeg du skal regne med, inden for nok maks 1 år. Prøv at hør hvad LK mener om det? EDIT. Der må også være en del ældre alarm installationer som har eller får problemer.

Så vidt jeg husker, så er 3G både til tale, sms og data. Derfor bruges der som minimum efterhånden kun 3G til alt. 4G er først kommet med tale inde for de sidste par år. Før det så var den brugt til sms og data. At 2G overhovedet lever i dag, det skyldes primært en "fall-back" når dækningen ikke er god nok. 2G er tale og sms, men ikke data, og vistnok heller ikke mms. TDC (Yousee) har vist fjernet deres 2G eller så sker det senere i år.

Jeg går ud fra, at de to eksempler, (både Henning og Klaus´s, men ikke begge samtidig), skal indsættes før Varmestyrings FBén? Altså, temperatur sensoren skal på D-Filter input. Og fra D-Filter output direkte til varmestyrings FB, hvor temperatur sensoren normalt ville gå ind?

Det er ikke så meget jeg har nået at få boret i det her problem, i og med mit først er blevet værre på det seneste. Men jeg har en lille mistanke om, at det hænger sammen med hvad IHC controlleren laver på det tidspunkt man sender en kommando til den. Jeg har flere items som går ind og aktivere tryk på IHC controlleren. Disse giver stort set aldrig problemer. Derudover har jeg gang i en "test", hvor jeg bruger en Z-ware PIR til at gå ind og aktiver en PIR timer i IHC controlleren. Og det er som er begyndt at give problemer, ret store faktisk, så jeg har måtte afbryde rulen for den. Jeg mistænker derfor, at det er når IHC controlleren er i gang med at tælle ned, at den har svært ved at modtage en kommando igen. Men jeg skal have boret lidt mere i det, bla ved at aktivere nogle af de tryk, som der ellers ikke giver problemer.

Direkte i tavlen? Der er jo ikke tale om en enkelt, men derimod 12 sensorer spredt ud i hele huset. Det pudsige er, at jeg har også to temp/fugt sensorer. De har tilsyneladende ikke problemet. Kan man i Visual vælge log værdiskifte? Og hvad vil det i givet fald betyde. Det er jo temmelig mange værdiskifte, taget i betragtning af, at "fænomenet" kun opstår periodisk. Her er fx et billede fra sensoren på mit hjemmekontor. Som det ses ud af grafen, så er det sket 2 gange inde for det sidste døgn, (både i - og + åbenbart).