Ole

CTR.RESTORE.FACTORY.DEFAULT View File Firmware RESTORE.FACTORY.DEFAULT for Visual 3 Submitter Ole Submitted 01/11/2019 Category IHC Control Visual 3 Firmware  

CTR.R.03.03.09 View File Firmware 03.03.09 for Visual 3 Submitter Ole Submitted 01/11/2019 Category IHC Control Visual 3 Firmware  

CTR.R.03.03.07 View File Firmware 03.03.07 for Visual 3 Submitter Ole Submitted 11-01-2019 Category IHC Control Visual 3 Firmware  

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

Velbekomme, håber det fik din Visual 3 på benene igen! @Gert Kjerslevmå jeg foreslå at oprette en Visual 3 download sektion under firmwares, så kunne vi samle dem der? Hilsner Ole.

CTR.R.03.03.09.fwf

Hvis jeg forstår din bekymring ret, så er den at du i dag styrer nogle af dine dimmer komponenter via den omtalte touch indgang - det vil sige én udgang på en funktionsblok, eller direkte fra et tryk. Det først nævnte var mit scenarie inden jeg udskiftede dimmer komponenten til følgende. Det kan du komme ud over ved at skyde eksempelvis 1.2.03.d ind i mellem - giver det mening? Hilsner Ole.

LK skriver følgende: http://www.lk.dk/mit-lk/ihc-software Software 03.04.54 Wireless touch lysdæmpere er udgået Muligheden for at sende projekter med touch produkter er blokeret Software 03.04.49 Denne software kan bruges midlertidig til eksisterende projekter der indeholde Wireless touch produkter. ADVARSEL.: Brug af denne software kan medføre fejl i programmet ved anvendelse af Wireless Touch lysdæmpere Jeg tolker det således, at brug af wireless dimmere via komponenten med touch indgang stærkt frarådes, og LK har valgt i seneste udgave af Visual softwaren at blokere for download af projekt, hvor denne komponent indgår. I december skiftede jeg fra HW6.1 til HW7.1 kontroller, og i mit gamle projekt havde jeg flere forekomster af netop denne wireless komponent med touch indgang. Jeg valgte i første omgang at benytte Visual version 03.04.09, som tillader download af projekt med denne komponent, og det virkede fint. Siden gik jeg i gang med at modificere mit program, og udskifte komponenten til udgaven uden touch indgang. Det program kører jeg med nu, og det virker selvfølgeligt også. Men jeg vil da skynde mig at tilføje, at jeg som så mange andre også erfare manglende wireless stabilitet. Jeg kan genkende @Coralreef problemstilling. Måden jeg har god erfaring med løser problemstillingen, er at unlinke den eller de wireless produkter der giver oplevelsen (jeg har aldrig oplevet at problemet opstår med mere end to af gangen), linker på ny, gemmer min Visual fil og laver en download. Jeg har en fornemmelse af, at problemstillingen som oftest er opstået i perioder hvor jeg har rodet med programmet, med flere downloads til følge. Hilsner Ole

Hejsa, Under overgangen til Visual 3 / HW 7.1 kontroller, har jeg flyttet el måler puls fra almindeligt 24/3 input modul, til S0 indgangen. Jeg er egentlig vældig tilfreds med de informationer S0 inputtet giver i Visual, men kan det virkelig passe, at forbrug til dato (Consumption) nulstilles ved kontroller genstart? Det er min erfaring, og jeg kan ikke finde en indstilling der giver mulighed for "Gem aktuel værdi ved strømsvigt" Hilsner Ole.

Hej Jess, Jeg benytter selv langt tryk til at slukke alt lys i rum, og stoppe B&O musikafspilning. Og jeg tror bestemt ikke tanken er at B&O skal være en form for "master" i opsætningen. Inden du har det "lange tryk" tilgængeligt til brug sammen med en macro, skal du huske at markere resourcen som en der skal "lyttes på" Det kan du gøre ved at trykke [Add resources] nederst på Devices->IHC/LexControl configuration siden. Her kan du se jeg lytter på funktionsblokkens kort og lang udgang - derfor der ikke er mulighed for at sætte et flueben. Når du har sikret dig det, så bør du også kunne bruge dit "lange tryk" i din macro. I mit tilfælde ser det sådan ud. Giver det mening? Hilsner Ole.

Hejsa, Beklager min sene kommentar, men jeg kan åbenbart ikke hitte ud af at abonnere, så jeg modtager e-mail ved navne tag. Angående kort lang tryk, hvis ellers jeg forstår dig ret og det stadig er relevant, så tror jeg ikke du kan få MLGW'en til selv at skele mellem kort og lang tryk. Jeg ville i min projektfil gøre brug af 4.15.a Kort-lang tryk, og så lade MLGW'en lytte på "udgang kort" og "udgang lang" Vil det ikke være en mulighed for dig? BH Ole

Hejsa, Under overgangen til Visual 3 / HW 7.1 kontroller, har jeg været i gang med at modificere min ude lys blok, så den benytter sig af helligdags funktionen. Det volder i mellemtiden nogen udfordring. Det virker som om, at så snart jeg modificere min funktionsblok til at have helligdags input, og gør brug af den, så fejler download til kontrolleren konsekvent. Efterfølgende melder kontrolleren at den kører i fejltilstand, ind til jeg gendanner fra SD kort, eller indlæser nulstillings FW og starter helt på en frisk. Følgende er fejlmeddelelsen jeg modtager, når projektfilen indeholder en funktionsblok der gør brug af helligdags input. Jeg forestiller mig at det er samme fejl @Jesper B beskriver her og som jeg er usikker på om der viste sig en løsning på!? Jeg kan konstatere, at så længe jeg kun forsyner funktionsblokken med helligdags input, og ikke gør brug af den inde i blokken, så fejler download ikke. Men så snart jeg vælger at medtage helligdags input i en betingelse, så kommer fejlen . Er der nogen som er bekendt med en officiel LK blok, som benytter helligdags funktionen, eller alternativt nogen som har en egen fabrikeret funktionsblok, der gør? Så kunne jeg have stor interesse i at prøve at lade den indgå i min projektfil, for at se om jeg har held til at gennemføre download. Jeg kører med nyeste FW (CTR.R.03.03.09), og som LK anbefaler uden helligdag opdaterings funktion aktiveret. https://www.lk.dk/mit-lk/ihc-software Flere der har oplevet det samme, og hvis løst, hvordan? :-) BH Ole 9.09.2 OBJ LK IHC Standard Ude.ifb

Se side 67 i denne her. Kamstrup Multical 21.pdf

Hej Ulrich, Enden blev, at jeg kontaktede mit vandværk, for at høre om de ville samarbejde om en løsning. Jeg forklarede hvad jeg gerne ville (have adgang til puls udgang), hvilket den måler jeg har siddende ikke giver mulighed for. (kan ikke lige huske fabrikat - ikke Kamstrup) Vandværet oplyste at dels grundet ringe stabilitet i fjernaflæsningen, dels dårlig erfaring med holdbarheden, var man netop i gang med en løbende udskiftning til Multical 21 fra Kamstrup af. Denne giver mulighed for adgang til puls udgang, og de var imødekommende for at give adgang til den, hellere end at jeg opsatte en ekstra måler, uden de ville / kunne forbyde det. Så lige nu venter jeg tålmodigt på, at de kommer til udskiftning hos mig. :-) Hilsner Ole.

@EjvindHald May I ask if you have completely made a switchover from Paulis OH1 IHC binding, to the OH2 IHC binding? And if so, how is your experience? The starting point for my OH use, was your "best practice" post last year, why I guess a switchover for me some way will be similar. Thanks in advance. Best regards Ole.

Hi @EjvindHald, I don’t think our approach is much different. It is very important to me too, to keep all major logic in the IHC controller. However, i feel comfortable in this case, letting OpenHAB hold the logic / calculate the need for garden watering. Some of the weather information is gathered from a Netatmo weather station, some from OpenWeatherMap. Until now garden watering has been activated by pressing an IHC push button, and the watering has been going on in a static amount of time (defined timer value). Now this timer value is variable, and the IHC push button is then activated from OpenHAB. If this logic in OpenHAB fails, the only thing happens is, that the flowers wither. ;-) Best regards Ole.

@Pauli Anttila Have just modified my item definition according to your explanasion, and now it Works like a charm. Thank you. @EjvindHald I will try. With some OpenHAB rules, I try to determine the daily garden-watering needs, based on humidity, clouds, wind, temperature and precipitation. Depending on that, I want to adjust the timer value on my "IHC garden watering function block". And I think I have succeeded to do that now. My plan B was to modify the "IHC garden watering function block" with several inputs, triggering different timers with different values. But I think adjusting the timer value from time to time is a nicer solution. Does that make sense?

@Pauli Anttila I think you understand my needs. I wish to adjust IHC timer values from OpenHAB. Regarding the IHC "Timer" tag, it represents the actual value counting up / counting down when the timer is activated. It generates a lot of updates when an OpenHAB item is bound to the tag, and I'm sure that you are right, when telling it's not wise to do so. And either, it is not my need. That is why I am playing with the IHC "TimerTid" tag. If I understand you correct, the only thing I have to change is to add a ">" to the item definition so its like: Number U_TimerVand "Timerværdi for vanding [%.0f]" <time> {ihc=">0x1102410"} I will try that tonight. Thanks a lot. Not according to the documentation, if I understand it correct, please have a look on my second post. BR Ole

@Pauli Anttila Can I ask you, if it should be possible to control "IHC Timertid" values from OpenHAB via your version 1 binding? My experience is, that changes made to the tag in the IHC controller updates the item value in OpenHAB, but changes made to item in OpenHAB does not update the "IHC Timertid" tag in the controller. Hope it make sense what I'm trying to achieve. Best regards Ole.

En lille opdatering på denne her. Jeg har modificeret min IHC funktionsblok, således at jeg gør brug af "Timertid" i stedet for "Timer". Det vil sige når jeg trigger timeren, starter jeg med at overføre timertid, så det er værdien af denne timeren gør brug af. En lille korrektion, modsat som jeg skrev i en tidligere post, selv om jeg synes det var min erfaring, så sker der nedtælling på mit item, når timeren trigges. Udlæser jeg ligeledes mit "IHC Timertid" item via sitemap, er værdien her den der er angivet i controlleren, eksempelvis 00:00:10:000 vises som 10000. Min oplevelse er, at hvis jeg overskriver denne værdi i OpenHAB, er det den nye værdi item'et får og dermed det der vises på mit sitemap, men kigger jeg i ServiceView overskrives værdien ikke i IHC controlleren. Retter jeg Timertid værdien via ServiceView, opdateres mit item i OpenHAB med den nye værdi. Så det er altså ikke lykkedes mig at kontrollere timertiden fra OpenHAB af. @EjvindHald, må jeg spørge dig om du har erfaringer med at kontrollere timertider i IHC controlleren via OpenHAB. Jeg overvejer at kaste mig over Paulis opdaterede IHC binding for at finde ud af om der er mere held ved det. Hilsner Ole.

@Danni k det tror jeg du har ret i, var ved at teste på det i går aftes, men det blev sengetid. Jeg laver lige en opdatering her, når jeg (forhåbentlig) kommer i mål. :-) /Ole