Jump to content
  • 0

Erfaring med IHC Visual 3.0


Michael R. Christensen
 Share

Question

Hej.

Hvad er jeres erfaring med IHC 3, min gamle controller 2 har kørt fint de sidste 11 år. 

Men er begyndt at midste sin ip addr, eller det vil sige at den er på netværket men svare ikke.

Troede i starten det var Openhab der var noget i vejen med, det er det ikke, svare ikke på ping eller på port test, der er kun en vej power reset controller.

1. Er den "nye" controller blevet bedre.

2. Køre de stadig med TLSv1

3. Køre software i Windows 10, uden at skulle lave alle mulige krumspring.

3. Virker webinterface, uden "IHC starter" (Mærkelig løsning at lave, bare for ikke at lave det ordenligt)

4. Kan jeg bruge min gamle "VIS" fil.

5. Virker den med Openhab, det skulle den... men gør den ??

Link to comment
Share on other sites

20 answers to this question

Recommended Posts

  • 1

openHAB web adgang er indefra og ud, så der er ingen eksterne porte åben. Virker formentlig via 'long polling' eller lignende - jeg tror ikke, at det er problemet.

Se dette link med indlægget fra @Claus Skovgaardden 7. februar 2017. Han konstaterer her, at ved firmware 2.8.x er det tilsyneladende nødvendigt med en højere timeout end standard + en keep alive rule. Formentlig en svaghed i IHC controlleren. Syntaxen i hans Item file er fra openHAB version 1, og den skal tilpasses til version 3. Timeout sætter du i UI eller Thing file, og reglen er formentlig identisk.

Prøv om det virker.

Link to comment
Share on other sites

  • 0
3 timer siden, Michael R. Christensen skrev:

Hej Mikkel.

Køre du selv med den nye ??  og køre du OpenHab 3.1 ??

Jeg har den nye til at sidde i et lab setup :)

Nej jeg kører ikke fast OpenHab. 

Det med den gamle dør/hænger kan være fordi du overvejer for meget/poller den for meget. Den måde OpenHab gør det på er lidt aggresivt sidst jeg så på det.

Link to comment
Share on other sites

  • 0

openhab bindingen angiver ressourcer, som controlleren skal holde øje med. Kun ved ændringer i disse sendes et event ud.

Dette er identisk med den måde, som de fleste andre apps tilgår controlleren. Det sikrer en minimum belastning.

Den seneste ændring er udelukkende en forbedret identifikation af status på controlleren ifm. genstart. Det kan fx være ved upload af en ny version af dit Visual projekt.

Link to comment
Share on other sites

  • 0
1 time siden, Michael R. Christensen skrev:

Den går død efter et par timer, og kommer selv igen et par timer efter.

Hvilken version firmware bruger du?

Har du “døde” input, hvor der er tiknyttet sensorer - fx temperatur -, men ingen anvendelse i projektet?

Har du en thing file, eller bruger du autodetect i openhab?

Link to comment
Share on other sites

  • 0
19 timer siden, Michael R. Christensen skrev:

Har overvejet det samme, kan desvære bare ikke finde en måde at sætte poll ned, tænker også det er ligt mærkeligt at Controller skulle død på KUN Lan interface.

Den går død efter et par timer, og kommer selv igen et par timer efter.

Det er ikke LAN interfacet som går død, men webserver/viewer delen i IHC controlleren. Der kan være mange årsager til dette. Både det som Ejvind og Michael skriver er helt klart i top 3. En anden typisk årsag er hacker angreb udefra hvis du har internet adgang til controlleren. Hacker scanner konstant internettet for sårbare enheder, og når de finder en IP som svare, skyder de række forskellige request af sted for at finde ud af hvad det er for en enhed. Disse request får næsten altid IHC controllerens webserver til at gå ned. De prøver gerne flere gange i en til 2 uger før de giver op.

Link to comment
Share on other sites

  • 0
18 timer siden, EjvindHald skrev:

Hvilken version firmware bruger du?

Har du “døde” input, hvor der er tiknyttet sensorer - fx temperatur -, men ingen anvendelse i projektet?

Har du en thing file, eller bruger du autodetect i openhab?

HW 6.2 Firmware 2.8.4.

Har brugt autoload af projekt fil, dette er slået fra igen, da det gik helt galt.

Har slette alle de "Channels" jeg ikke bruger til noget, det sjove er jo at det har kørt fint i mange år.

Var selv på Github igår for at se hvad der var ændret, kan godt se det ikke har noget med dette at gøre.

Går ud fra at der ikke er nogle forskel på om jeg bruger autoload og sletter alt det jeg ikke bruger, eller laver en Thing file.

Så jeg tror sådan set heller ikke det har noget med opdatering til 3.1, har holdt lidt øje med den på job idag, den startet med at lave "javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake" og der efter "java.net.NoRouteToHostException: No route to host (Host unreachable)"

Og det er ikke fordi der er så mange ting den skal holde øje med, der er udgange og to termostater, check i logtail, det køre fint og roligt.

Så er det bare at vente en times tid, så er den der igen, eller disable Thing og power resette controller.

Link to comment
Share on other sites

  • 0
36 minutter siden, Lars1 skrev:

Det er ikke LAN interfacet som går død, men webserver/viewer delen i IHC controlleren. Der kan være mange årsager til dette. Både det som Ejvind og Michael skriver er helt klart i top 3. En anden typisk årsag er hacker angreb udefra hvis du har internet adgang til controlleren. Hacker scanner konstant internettet for sårbare enheder, og når de finder en IP som svare, skyder de række forskellige request af sted for at finde ud af hvad det er for en enhed. Disse request får næsten altid IHC controllerens webserver til at gå ned. De prøver gerne flere gange i en til 2 uger før de giver op.

Min Controller vender ikke mod internettet, ikke med TLSv1. Openhab vender mod internettet, men ligger bag min firewall og apache.

Link to comment
Share on other sites

  • 0
1 time siden, Michael R. Christensen skrev:

Min Controller vender ikke mod internettet, ikke med TLSv1. Openhab vender mod internettet, men ligger bag min firewall og apache.

Openhab eller tilsvarende mellem IHC controllerne og internettet beskytter den hackers forsøg på at hacke den. En standard firewall eller selv den stærkeste krypterings gør ikke. Det er hackernes forsøg på at få adgang som lægger IHC controlerens webserver ned.

Det er ikke sådan at du har fået hacket din OpenHab installation og de nu forsøger at få adgang til næste enhed via deres OpenHab adgang?

Link to comment
Share on other sites

  • 0
20 minutter siden, Lars1 skrev:

Openhab eller tilsvarende mellem IHC controllerne og internettet beskytter den hackers forsøg på at hacke den. En standard firewall gøre ikke.

Det er ikke sådan at du har fået hacket din OpenHab installation og de nu forsøger at få adgang til næste enhed via deres OpenHab adgang?

Ja det er jeg sikker på, nu ved jeg jo ikke hvad du syndes en "Stardard firewall" er ?? der er kun den trafik på firewall og div logs jeg forventer. 

Link to comment
Share on other sites

  • 0
1 time siden, Michael R. Christensen skrev:

HW 6.2 Firmware 2.8.4.

Har brugt autoload af projekt fil, dette er slået fra igen, da det gik helt galt.

Har slette alle de "Channels" jeg ikke bruger til noget, det sjove er jo at det har kørt fint i mange år.

Var selv på Github igår for at se hvad der var ændret, kan godt se det ikke har noget med dette at gøre.

Går ud fra at der ikke er nogle forskel på om jeg bruger autoload og sletter alt det jeg ikke bruger, eller laver en Thing file.

Så jeg tror sådan set heller ikke det har noget med opdatering til 3.1, har holdt lidt øje med den på job idag, den startet med at lave "javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake" og der efter "java.net.NoRouteToHostException: No route to host (Host unreachable)"

Og det er ikke fordi der er så mange ting den skal holde øje med, der er udgange og to termostater, check i logtail, det køre fint og roligt.

Så er det bare at vente en times tid, så er den der igen, eller disable Thing og power resette controller.

TLVv1 er "enable" igen i security file, og "thing" er sat op til TLSv1

Link to comment
Share on other sites

  • 0
8 minutter siden, EjvindHald skrev:

openHAB web adgang er indefra og ud, så der er ingen eksterne porte åben. Virker formentlig via 'long polling' eller lignende - jeg tror ikke, at det er problemet.

Se dette link med indlægget fra @Claus Skovgaardden 7. februar 2017. Han konstaterer her, at ved firmware 2.8.x er det tilsyneladende nødvendigt med en højere timeout end standard + en keep alive rule. Formentlig en svaghed i IHC controlleren. Syntaxen i hans Item file er fra openHAB version 1, og den skal tilpasses til version 3. Timeout sætter du i UI eller Thing file, og reglen er formentlig identisk.

Prøv om det virker.

Det er netop det - man skal være forsigtig på de gamle versioner.

Link to comment
Share on other sites

  • 0
50 minutter siden, EjvindHald skrev:

openHAB web adgang er indefra og ud, så der er ingen eksterne porte åben. Virker formentlig via 'long polling' eller lignende - jeg tror ikke, at det er problemet.

Se dette link med indlægget fra @Claus Skovgaardden 7. februar 2017. Han konstaterer her, at ved firmware 2.8.x er det tilsyneladende nødvendigt med en højere timeout end standard + en keep alive rule. Formentlig en svaghed i IHC controlleren. Syntaxen i hans Item file er fra openHAB version 1, og den skal tilpasses til version 3. Timeout sætter du i UI eller Thing file, og reglen er formentlig identisk.

Prøv om det virker.

Hmm :), den er sgu sjov. 

Som jeg læser det, er det ikke nok at Openhab modtage events, men skal også sende events ??

Det prøver jeg, min timeout har stået til 20000 længe elles fik jeg timeout.

Jeg oprette et flag i IHC , og sender ON til det fra OH med 10-15 min interval. 

Link to comment
Share on other sites

  • 0
7 minutter siden, EjvindHald skrev:

Har du andre ting koblet til Controlleren - fx IHC Captain?

Nej..... Kun OH3,  Har lige kørt med "Home Assistant" bare for at se om det var controlleren, det kørte fint i et par dage(Ikke på sammetid) fik ingen fejl der. 

Det er bare ikke lige mig, det var super nemt at sætte op....... meeeeen der er ikke Openhab :)

Link to comment
Share on other sites

  • 0
5 timer siden, Michael R. Christensen skrev:

Ja det er jeg sikker på, nu ved jeg jo ikke hvad du syndes en "Stardard firewall" er ?? der er kun den trafik på firewall og div logs jeg forventer. 

En standard firewall er en firewall hvor du kan lave basale port åbninger, NAT regler og tilsvarende. Nogenlunde hvad du kan i en standard router fra en ISP idag. En avanceret eller professionel firewall har packet inspections, intrution detection, intrution prevention etc. Disse firewalls koster fra 15K og op.

Link to comment
Share on other sites

  • 0
På 26.10.2021 at 18:15 , EjvindHald skrev:

openHAB web adgang er indefra og ud, så der er ingen eksterne porte åben. Virker formentlig via 'long polling' eller lignende - jeg tror ikke, at det er problemet.

Se dette link med indlægget fra @Claus Skovgaardden 7. februar 2017. Han konstaterer her, at ved firmware 2.8.x er det tilsyneladende nødvendigt med en højere timeout end standard + en keep alive rule. Formentlig en svaghed i IHC controlleren. Syntaxen i hans Item file er fra openHAB version 1, og den skal tilpasses til version 3. Timeout sætter du i UI eller Thing file, og reglen er formentlig identisk.

Prøv om det virker.

Okay :) det er sgu sjovt, det ser ud til at virke, sender kommando til flag i IHC controlleren.

Har været online nu i næsten 24 timer, sjovt jeg først løber ind i den fejl nu, jeg kan ikke huske hvornår jeg har opgraderet med ny firmware sikkert flere år siden, og den fejl har jeg aldrig haft før nu.

Nå men jeg håber det holder, sparet lige 5K

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...

Important Information

Privacy Policy og We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.

1200x630bb.png

ok