Astronaut

Næh. Fejlen ligger helt sikkert et sted i controlleren. For det program jeg uploadede til sidst havde jeg først downloaded fra controlleren. Jeg havde *ingen* backup til at starte med (ja ... jeg en idiot ... nogen gange). Processen var således (firmware upgrade/downgrade sprunget over fordi de sandsynligvis ingen forskel gjorde): Download program fra controller (samme program havde kørt i månedsvis) Upload tomt program Upload program fra trin 1. Dette er blot endnu et eksempel på at IHC visual 2/3 controlleren er problematisk rent software mæssigt. Det samme hvor en opgradering dræber controlleren. Jeg er ikke sikker på at min investering i IHC denne gang var en god ide. Min gamle IHC visual 1 installation var jeg fantastisk glad for. Den nye ... PS: Som jeg forstår det kører controlleren faktisk Linux som OS ... åbenbart med Java ovenpå.

I IHC Service Viewer (og i IHC Captain hvor jeg kunne cut and paste).

Jeg fik liv i skidtet. I loggen står der: 2019.07.28 20:53:13 Fatal DEBUG: VITAL THREAD Rf master Thread DIED: java.lang.NullPointerException Det undrer mig hvis controlleren kører java, men måske er det bare formatteringen af beskeden der går galt. Anyway, downgrade af firmware virkede ikke (i sig selv). Reset af controller hjalp ikke. Sluk/tænd af IHC strømforsyning virkede ikke. Her er hvad jeg gjorde: Downgrade af firmware til 03.03.18 (jeg tror ikke det var nødvendigt) Upload af tomt projekt til controlleren Upgrade af firmware til 03.03.21 Upload af orginalt projekt

Har du noget forslag til at få den ud af fejltilstand?

Det ser ud til at der er gået noget galt på RF siden. Her er linkning til wireless produkter:

Jeg forsøgte at installere firmware 03.03.23 … nu er min controller i fejltilstand. Jeg opdaterede over netværket. Firmware loaderen rapporterede om succes. Not so much. Har genstartet. Har trykket på reset. Har opdateret firmware endnu engang.

Ok. Tusind tak. Jeg går ud fra at man skal slukke controlleren når man tager det ud? Anyway, det lyder som det vil være en god ide at lave et image af SD kortet ... blot til hvis kortet dør. Og som du selv skriver er der også den udvej at formatere et nyt kort i ext3 format og så håbe at controlleren selv opretter den rigtige filstruktur når den mangler. Hvilken controller har du?

Jeg har såmænd gjort begge dele. Jeg har enten ikke fundet svar eller potentielt modstridende svar. Fx. skriver LK at SD kortet indeholder en backup af programmet og logbeskeder. Men samtidigt er der folk som siger at et beskadiget kort forhindrer controlleren i at virke. Det synes ikke at hænge sammen - manglende backup burde ikke stoppe controlleren. Derfor spørgsmålene ...

Er der nogen specielle forholdsregler jeg skal tage hvis jeg vil lave et image af mit SD kort? Hvad ligger der på kortet? Kan controlleren starte uden SD kort? Hvordan sletter man logfiler på SD kortet? Kan man sætte et større SD kort i? Hvor meget skriver controlleren på kortet? Kan det betale sig at købe et "high endurance" eller "industrial" kort?

Hvis du har en der virker til wireless så vil jeg gerne se den. For jeg er kommet frem til at wireless ikke pålideligt kan detektere 3 hurtige tryk efter hinanden og jeg vil meget gerne opdage at jeg tager fejl.

Der synes at være noget galt med det raspberry pi 1.06 image som man kan downloade. Det virker for så vidt fint, men man kan ikke expande filsystemet. Jeg får følgende fejl: May 30 20:40:02 IHCcaptain resize2fs_once[264]: Starting resize2fs_once:resize2fs 1.43.4 (31-Jan-2017) May 30 20:40:02 IHCcaptain kernel: [ 30.200780] EXT4-fs (mmcblk0p2): resizing filesystem from 524288 to 955776 blocks May 30 20:40:02 IHCcaptain kernel: [ 30.200837] EXT4-fs error (device mmcblk0p2): ext4_iget:4697: inode #7: comm resize2fs: bad extra_isize 70 (inode size 256) May 30 20:40:03 IHCcaptain kernel: [ 30.810024] EXT4-fs warning (device mmcblk0p2): ext4_resize_fs:1939: Error opening resize inode May 30 20:40:09 IHCcaptain resize2fs_once[264]: resize2fs: Structure needs cleaning While checking for on-line resizing support May 30 20:40:09 IHCcaptain resize2fs_once[264]: Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required May 30 20:40:09 IHCcaptain resize2fs_once[264]: old_desc_blocks = 1, new_desc_blocks = 1 May 30 20:40:09 IHCcaptain systemd[1]: resize2fs_once.service: Control process exited, code=exited status=1 May 30 20:40:09 IHCcaptain systemd[1]: Failed to start LSB: Resize the root filesystem to fill partition. May 30 20:40:09 IHCcaptain systemd[1]: resize2fs_once.service: Unit entered failed state. May 30 20:40:09 IHCcaptain systemd[1]: resize2fs_once.service: Failed with result 'exit-code'. Jeg har forsøgt med flere forskellige SD kort og flere forskellige Pi'er. Samme fejl. Under normale omstændigheder har man selvfølgeligt slet ikke brug for at expande filsystemet, men jeg havde brug for at smide nogle ting på en linux box og min captain box var "nærmest". Derfor behovet. Anyway, nu har jeg installeret IHC captain manuelt og det virker fint.

Jeg tror mere problemet er den protocol LK har valgt, for selv med forsinkelse kunne man godt lave en løsning der virker. Anyway, jeg har testet det på min V3 controller og det virker ikke ordentligt med flere hurtige tryk i rækkefølge. Jeg prøvede at lave en simpel tæller der talte op hver gang tangenten gik fra OFF->ON. Ingen timing eller noget. Hvis man trykker hurtigt så mister controlleren nogle tryk. Jeg har ikke lavet en videnskabelig undersøgelse, men der skal vist helst være mindst ca. 0.5 sek mellem tryk. Og det ødelægger interaktionen. Enig. Har dog ikke testet fortrådede tangenter fordi min nye installation er næsten 100% wireless hvor den gamle var 100% fortrådet. Jeg har kørt med mine egne funktionsblokke i 15 år som håndterer multitryk. Det virker fint. Jeg har aldrig oplevet nogen problemer overhovedet - jeg har faktisk ikke rørt programmering af controlleren siden det blev sat i drift. Jeg bruger trippletryk flere gange hver dag i min fortrådede installation. Så hvis det er noget skrammel, så er det den slags skrammel der virker. Bare ikke med wireless. :-(

I øvrigt er IHC Visual 1 controlleren ganske fin. Ifbm. flytning er jeg nu skiftet til en IHC Visual 3 controller og den er ikke bedre på alle punkter. Firmwaren i V1 er god kvalitet, min har kørt i 15 år og kun krævet genstart en eneste gang; V3 firmwaren er decideret dårlig kvalitet. Her er hvad jeg mener er de vigtigste ting der mangler i V1 controlleren: V1 controlleren kan ikke wireless V1 controlleren kan ikke snakke med fx. IHC Captain; eneste interaktion er gennem inputs og outputs V1 controlleren kræver RS232 for programmering; nyere kan programmeres over netværket V1 controlleren har ikke scenarier (kun vigtigt vigtigt med lysdæmpere) V1 controlleren kan ikke snakke med temperaturfølere, etc. Bestem dig for om noget af ovenstående er vigtigt for dig. Hvis ikke så er din V1 controller en fin løsning. Brug tid på at eksperimentere med programmering af den - du kan bruge næsten alt den viden hvis du senere skifter til en nyere controller. Min største anker ved V3 controlleren er: Lav kvalitet af firmware; det er tydeligt at den del af koden som er udviklet de senere år er af meget lavere kvalitet Lukket system; en gateway til andre standarder som fx. KNX ville gøre systemet mere fremtidssikret Wireless tillader ikke hurtige inputs fra tangenter. For eksempel har jeg til V1 controlleren en funktionsblok der detekterer multiple hurtige tryk på en tangent (fx. vil 3 hurtige tryk nederst til højre altid slukke alt lys i alle rum). Dette giver mulighed for ca. 20 forskellige funktioner i en enkelt 4 tryks input. Med V3 controlleren og wireless tangenter er det ikke mulig at lave noget ordentligt omkring multi-tryk pga. den lave hastighed.

Jeg skal bruge et par ringeklokker. De skal kunne styres med 24V og de skal kunne give mindst 3 forskellige tonesekvenser. Hvis de samtidigt kunne lave en "alarm lyd" ville det være fint, men det er ikke påkrævet. Er der nogen der har erfaring med den slags?

Det er jeg glad for at høre. Men selv at skifte controller kan tage lang tid. Så jeg forsøger at være forsigtig. Åbenbart ikke forsigtig nok med seneste firmware. Jeg synes din IHC captain løsning er excelent (selvom jeg gerne så den kunne endnu mere ). Jeg har prøvet at sætte NTP server med IHC captain. Her er hvad jeg oplever: Softwaren er temmelig strict omkring hvad den tillader. Den burde ikke have nogen krav til hostname. Fx. accepterer den ikke otto.er.et.naesehorn som NTP server. Min NTP server har et navn der ligner det mønster. Selv når jeg blog vælger dk.pool.ntp.org, så bliver ændringen ikke gemt (selvom IHC captain siger data er gemt). Når jeg forsøger at enable "Benyt tidsserver" sker det samme - ændringer bliver ikke gemt selvom IHC captain siger at de er gemt.

Jeg ved ikke rigtigt hvad jeg vil gøre. I første omgang handlede det mest om at være sikker på at det ikke var mig der gjorde noget forkert. Der har været flere historier om controllere der er gået i permanent "udu" ifbm. opgradering af firmware så jeg er også lidt forsigtig med at op eller nedgradere. I det hele taget må jeg erkende at skiftet fra en Visual 1 til Visual 3 controller har været en øjeåbner omkring manglende software kvalitet. Software kvaliteten hos LK er helt klart meget ringe - både UI, arkitektur, teknik og udførelse lader meget tilbage. Modsat den oprindelige visual controller.

Jeg har en Visual 3 controller der kører den nye 3.3.21 firmware. I forbindelse med omlægning af netværket fik jeg behov for at opdatere NTP (tidsserver) opsætningen. Desværre synes den nyeste firmware ikke at acceptere nogen som helst tidsserver (inkl. schneiders egen pool). Det virkede fint med foregående version og controlleren kunne også opdatere tid med 3.3.21 efter opgradering. Men da jeg forsøgte at ændre settings får jeg besked om at serveren ikke kan få fat i tidsserveren uanset hvilken server jeg vælger. Af samme grund vil den ikke acceptere ændringen. Jeg forsøgte at skifte til manuelt tidsinput og det virker, men nu kan jeg ikke skifte tilbage. Jeg har testet at der er forbindelse til de forskellige tidsservere. Er der nogen der har oplevet samme problem? Er der nogen der har skiftet tidsserver under 3.3.21?

Selvfølgeligt. Jeg får også penge for mit arbejde. Men jeg tænker også over hvad jeg bruger dem til og det er svært at retfærdiggøre at bruge mange penge på noget som for mit vedkommende mest er legetøj. Det er naturligvis anderledes for andre. Men som sagt, jeg synes det er flot lavet.

Jeg læste i går i beskrivelsen til applikationen IHCDroid at websceneview er fjernet i Visual 3 controlleren fra og med firmware version 3.3.9. Jeg kan ikke finde nogen firmware changelog så jeg kan ikke konfirmere dette. Dette på trods af at LK beskriver WebSceneView i manualen. Det ser flot ud men er sikkert også dyrt. Jeg vil også gerne have noget jeg selv kan konfigurere uden at skulle involvere andre. Jeg tror jeg ender med at leve med LK's latterlige app indtil videre - jeg skal have fundet ud af begrænsningerne i appen. Det kan være at jeg efter sommeren giver mig i kast med at kode noget nyt selv til Android. Jeg skal også have set om IHCCaptain e.lign. kan gøre noget af det jeg gerne vil. Måske kunne man endda udvide systemer som IHCCaptain med et App interface sådan at det fungerede mere flydende for små devices. Vi får se. Lige nu har jeg 15 års IHC Visual 1 erfaring og 2 måneders IHC Visual 3 erfaringer som skal omsættes til noget fornuftigt.

Jeg downloadede Visual fra LK's hjemmeside. Jeg har i øvrigt installeret det på flere computere med samme resultat. Men min umiddelbare opfattelse af hvordan controlleren virker, så er det også alt sammen noget der kommer fra controlleren. Når man starter SceneDesign op på den lokale PC, så henter den hele programmet fra controlleren. Så jeg ville forvente at det lå i firmwaren til controlleren. Mine forventninger er ikke så store, men lige nu har jeg kun LK's latterlige Android app som meget lidt kan. Sceneview lider under at det kræver Java og bruger en teknologi som ikke opdateres mere (JNLP). Jeg har pt. hverken iPad eller iPhone så jeg kan ikke bruge IHCTablet til noget. Det ville være en smule kedeligt at skulle købe en iPad blot til dette formål.

Jeg kan ikke finde noget spor af WebSceneView i administratoren. Jeg har følgende: Controlleren er sat op for et par måneder siden. Der er ikke adgang til controlleren fra internettet men controlleren kan selv få fat i internettet. Jeg har nu opdateret den til sidste nye firmware (3.3.21): Har jeg fat det gale sted? Jeg har kørt IHC i 15 år men det her er første gang med en Visual 3 controller (min gamle controller er en Visual 1 controller med RS232 programmering).

Ja, jeg har læst vejledningen. Jeg kan uden problemer komme ind i SceneDesign hvor jeg kan designe skærmbilleder der kan ses i SceneView (som er et Java program). Men som jeg forstår det skulle det også være muligt at komme ind i WebSceneDesign. Når jeg tilgår controllerens webside er der kun: LK IHC Administrator LK IHC ServiceView LK IHC SceneVIew LK IHC SceneDesign Onlinerapporter På min PC er installeret: LK IHC FirmwareLoader LK IHC SceneDesign (virker kun til USB) LK IHC Visual 3.04.53.03 (og så nogle websider) Jeg har læst dokumentationen som siger noget om at SceneDesign skulle kunne lave websider, men jeg kan ikke finde nogen funktionalitet til det. Så lige nu kan jeg ikke komme videre.

Hvordan designer man en web side? Jeg kan komme ind i SceneDesign og SceneView, men jeg kan ikke finde nogen steder hvor jeg kan lave en WebSceneView side. Jeg har en Visual 3 controller med 3.3.18 firmware.

Jeg er ganske enig. Jeg tror ikke datalinje produkterne forsvinder. Men jeg har svært ved at se nogen vælge samme arkitektur til noget i fremtiden. Det er ganske enkelt ikke den vej markedet bevæger sig. Du glemmer at for de fleste er det dyre at få en elektriker ud og lavet et fornuftigt kabeltræk. Og et tryk koster det ene eller andet betyder lidt. Jeg er ikke i tvivl om at LK har smidt en stor sum penge i IHC Wireless. Men det kan vi sikkert diskutere længe. Nej på ingen måde. En gateway som blot udstiller de forbundne datalinjer og/eller wireless produkter som KNX inputs og outputs behøver ikke være en kæmpe investering. Der hvor controlleren bliver dyr er når der skal laves programmeringssprog, editor, debugger, viewer, admin, etc. Alt det ville man slippe for hvis man lavede en dum gateway som blot exponerede det tilkoblede. LK skulle så blot opdatere firmwaren til gateway'en eller producere en ny hver gang der kom nye wireless komponenter til (hvis det sker). Min gamle IHC Visual 1 controller havde et program (ServiceViewer) der viste status af alle ind- og udgange. Principielt skal samme blot exponeres over KNX for datalinje produkter. Det er lidt mere kompliceret for wireless produkter. Vigtigst: det skulle være en gateway der ikke har netværsforbindelse. Netværksforbindelse kræver konstante opdateringer. Jeg har lidt større forventninger til et produkt der er del af min el-installation end at det ikke supporteres efter 2 år. Det er ikke et brug og smid væk produkt. Manglende opdateringer er ikke et problem for produkter der ikke er koblet til internettet - fx. er min gamle IHC Visual 1 controller ikke opdateret i 10-15 år. Det fungerer fint for der er ikke noget der kan hackes uden fysisk at dukke op i min bolig. Der hvor kæden falder af er når man kobler produkter på internettet som ikke bliver opdateret. Den slags vil blive hacket før eller siden når der findes fejl i software stakken. Min IHC Visual 3 controller er placeret på dens helt eget net - der er intet andet der og ingen internet adgang. Eneste adgang er gennem en VPN forbindelse. På den måde er jeg relativt sikker på at der ikke sker noget men det er ikke nogen optimal løsning.

Traditionelle el-installationer har været lavet ved at sløjfe stærkstrømskabler rundt i bygningen i mere end 100 år. Selve kabelinstallationen fejler meget sjældent. Med et fornuftigt bus-design vil enkelt nodes også have meget svært ved at fejle hele bussen og under alle omstændigheder kan man isolere et eller flere segmenter. Man kan fint komme uden om afstandsproblemer hvis arkitekturen er en kombination af stjerne og bus. Sådan at man har mulighed for at forgrene bussen. På den måde kan man vælge den installationsform der giver det nemmeste kabeltræk. Ideen er at undgå at alle kabler skal ende samme sted (i el-tavlen) og lange afstande med mange parallelle stærkstrømskabler. Begrænsning i antal indgange er ikke noget seriøst problem. Med en bus arkitektur, hvor et tryk sender en besked hver gang der sker noget, er der ingen forskel på et tryk med 1 eller 200 tangenter. I en veldesignet controller er det heller ikke noget problem fordi den blot kan ignorere ikke-konfigurerede indgange. Er der nogen dokumentation på RS485 porten? Under alle omstændigheder vil jeg på sigt gerne undgå LK's controller fordi den netop er et af de svage punkter i IHC. Som sagt burde det være relativt nemt at lave en gateway til datalinje produkterne - protokollen er meget simpel og kendt. LK eller andre kunne lave en gateway. LK har lavet en stor investering i IHC Wireless. Med en wireless gateway kan LK fortsætte med at sælge de relativt dyre wireless komponenter uden at skulle videreudvikle controlleren. Og controlleren er i min analyse det svage led i produktserien (fx. er det fuldstændigt vanvittigt at LK fra tid til anden efterlader kunderne med usupporterede controllere der kører en gammel og upatchet version af Java samtidigt med at controlleren er på nettet). Controlleren er også det dyreste produkt at løfte rent udviklingsmæssigt. LK kan lave en wireless gateway relativt billigt. Det burde også være muligt for andre at lave en wireless gateway hvis man reverse engineerer koden i enten LK's controller eller et eller flere wireless produkter. Som tidligere skrevet er komponenterne i LK's wireless produkter standard komponenter. Dvs. hele den proprietære protokol er implementeret i software.