Modules in VelbusLink met rood kruis - enkel bepaalde modules

Nederlands
1

Enkele modules in VelbusLink (versie 9.80.0.9) blijven met een rood kruis terugkeren.

Gaat vooral om knoppen type VMBGPOD (firmware versie 1612), eerst had ik vermoeden dat het kwam door de firmware versie, 2 knoppen (VMBGPOD) hadden een oudere firmwareversie. Heb die succesvol geupgrade naar de laatste versie.
=> maakt geen verschil voor issue.

2x Eindweerstanden ok, alle (die in fout gaan) schakelaars er al eens terug uit gehaald, maar geen enkele met eindweerstand, dus dat is het probleem ook niet. (volgens de handleiding en wat ik er van weet)

Bekabeling reeds dubbel gecheckt, alle schakelaars eruit gehaald en gecheckt op kleuren.

Als ik op de modules met rood kruis iets aanpas en schrijf “enkel wijzigingen” gaat het “meestal” goed. Soms moet ik eens “retry” kiezen maar komt telkens goed. Functioneren naar behoren.

Doe ik eens voor de probleem modules “schrijf alles, dus niet enkel wijzigingen” dan gaat hij na enkele ogenblikken in “time-out”.

enkel dit stuk in de logs eens export gedaan, zie bijlage velbuslink_17-04-2017.log.vlp (17.1 KB) (kon geen txt of log file uploaden (rename .vlp > .txt of .log)

Vervolgens een export log van een WRITE actie naar een module die wel direct lukt:

export_log_wel_geslaagde_write_actie.log.vlp (127.4 KB) (kon geen txt of log file uploaden (rename .vlp > .txt of .log)

Memory dump van een schakelaar met rood kruis (één van de voorbeelden)
memorydebug_17-04-2017.csv.vlp (92.3 KB) (csv hernoemd naar .csv.vlp > terug aanpassen naar .csv )

Uiteindelijk ook gezien dat er een module VMBGP2 ook met zo’n rood kruis staat. (firmware versie 1521) Ben hem nu ook aan het upgraden naar firmware versie 1625 zoals de andere VMBGP2 modules maar vrees dat het daarmee niet zal opgelost zijn.

Een tijd geleden heb ik met “try&error” 3x een VMBGPOD los gekoppeld en toen waren de problemen weg. Als die zelfde 3 nu terug toevoeg, firmware goed zet, is het probleem er terug. Lijkt me niet logisch, laat nu dus alles zitten tot ik probleem vind.

Bij het lezen van diezelfde modules gaat het blijkbaar ook niet goed op die modules:

image.png817×435 65 KB

Het zijn telkens dezelfde 13 modules (zie schets hieronder) die in fout gaan, niet toevallig opéénvolgend langs de bus kabel (UTP cat 6) en de eerste 13 die vertrekken vanaf de kast, erna 14 - 15 …gaat niet meer in de fout langs dezelfde bus kabel. Nochtans in de opeenvolging van de 13 schakelaars zit ook een relais module en input module voor kWh teller in een kleine kast (kast G op schets hieronder) en die gaan niet in de fout.

image.jpg833×655 33.8 KB

Schakelaar A,B (VMBGPOD) op bovenstaande schets zijn zelf onbruikbaar, ze reageren nog op links - rechts en/of click maar de 4 led’s pinken samen elke +/- 20sec.
Schakelaar C (VMBGPOD) die pinkt ook maar je kan de schakelaar wel nog gebruiken, functioneert nog gedeeltelijk.
Schakelaar D (VMBGPOD) die pinkt niet en reageert normaal.

Identiek dezelfde lees/schrijf acties met alle relais, andere schakelaars dan die 13 of dim of shutter modules geven geen problemen op dezelfde bus.

Iemand tips wat ik nog kan checken?

2

Het klinkt als een bekabelings- of terminatorprobleem, maar je hebt dit blijkbaar nagekeken… Wat ook mogelijk is, is dat ergens in de bekabeling een geleider afgebroken in de isolatie zit, komt vooral bij UTP-kabel voor. Dit is moeilijk te detecteren en geeft vreemde effecten aangezien het soms verbinding geeft, soms niet.

Ik zou het niet in firmware gaan zoeken en eigenlijk vermijden van in een installatie die niet optimaal werkt firmware upgrades te doen. Het feit dat modules niet gedetecteerd worden heeft in eerste instantie normaal gezien niet veel te maken met programmatie of firmware.

Wat zeker altijd aan te raden is bij vreemd gedrag is om even de spanning van de modules of de volledige installatie te halen, een paar seconden wachten, en dan spanning terug aanleggen.

Zijn de modules die niet reageren in lus verbonden? Zonee, sluit ze eens provisorisch in lus aan (dus van het einde van de kabel een verbinding maken terug naar de kast). Indien dit iets verandert, is het zo goed als zeker een bekabelingsprobleem.

Je kan ook de modules die problemen geven er allemaal af halen, en één voor één terug aansluiten en telkens scannen. Dat kan een idee geven van waar het probleem zich eerst voordoet.

Eventueel ook een kleine testopstelling maken met enkel USB-module en voeding, en elke module die problemen geeft daar eens apart op aansluiten. Dat geeft al wat meer info over de vraag of het aan de module(s) ligt of niet.

We zullen ondertussen ook de loggings en memory dumps eens bekijken…

3

Aan de screenshot is te zien dat de module met adres 58 niet gescand werd, in de logging is te zien dat naar die module geschreven wordt, maar dat ze op een gegeven moment (13:32:52:888) niet meer antwoordt (3 keer een delay van 1000ms tussen schrijfpogingen zonder antwoord van de module).
Mogelijks is er een firmware update slechts gedeeltelijk gelukt, en is ze nu gedeeltelijk onbruikbaar.

Je kan eens proberen om de module te isoleren in een kleine testopstelling (PC, USB-module, en korte buskabel naar module), en zo een firmware upgrade proberen. Krijg je ze in een testopstelling niet terug werkend, dan zal ze waarschijnlijk terug naar Velbus moeten voor service (via je aankoppkanaal).

(In de volgende release van Velbuslink zijn beveiligingen ingebouwd om mislukte firmware updates zoveel mogelijk te vermijden, en is het firmware update proces ook geoptimaliseerd.)

4

@VEL345 firmware upgrade was inderdaad eerste keer mislukt (windows update op laptop had er anders over beslist).
Uiteindelijk erna nog eens dezelfde actie succesvol kunnen doorlopen.

Firmware versies lijken er inderdaad niets mee te maken te hebben, had gehoopt van wel omdat er maar 1 schakelaar op een andere versie stond… niet dus. :frowning:

Alle schakelaars door de gehele woning zitten inderdaad in 1 lange lus, mocht het een bekabelingsprobleem zijn tussen de eerste 13 schakelaars in de lus (die dom doen) zou ik verwachten dat die kast “G” op mijn schets die ook tussen die 13 zitten ook zou dom doen…

Of heeft het volgens jou niets te maken met die eerste 13 en is dat gewoon omdat die eerst in de lus geplaatst zitten en kan de oorzaker ook verder zitten?

Laat ons hopen van niet… Zoek dat maar eens uit

Ik zal volgende proberen :

  1. eens alles zonder stroom plaatsen
  2. zoals je schrijft proberen elimineren wanneer probleem zich voordoet als ik schakelaars één voor één uitschakel.
  3. eventuele probleem schakelaars in een aparte lus op een voeding steken en testen.

Bedankt voor uw antwoord!

5

@VEL345

Heb nog eens alles uitgezocht, heb ook de terminators terug gezocht en uitgetekend op klein schema:

image.jpg1110×845 252 KB

Zitten ze correct? Max2 en zoveel mogelijk koper ertussen. Of betere vraag, kan dit de oorzaak zijn?

Zoals je ziet, in de kast zelf, is het niet echt een kring, daar werk ik met de VMBTB en VMBRAIL.
Vanuit de kast vertrekt er 1 kabel naar de eerste schakelaar (adres 0F) en dan een lus door het huis.
Vanaf de laatste schakelaar op zolder komt er 1 kabel terug naar de kast op de VMBTB.

Het zijn schakelaars 0F, 06, 45 ,1D, 18, 2A, 26, 44 die in de fout gaan, zoals je ziet op het schema zitten die opeenvolgend vertrekkend vanaf de VMBTB, als ik de verbinding tussen de VMBTB en schakelaar 0F verbreek, dan heb je uiteraard geen lus meer, maar alles blijft werken (logisch want dat mag).

Echter probleem blijft op diezelfde schakelaars en toch is er volgens mij niets verkeerd specifiek met die schakelaars.

Schema in betere kwaliteit want forum gaat die verkleinen: schema velbus netwerk.pdf.vlp (123.6 KB)
(rename van .*vlp naar *.pdf)

Probleem vergroot als je meer schakelaars gaat toevoegen, dan beginnen de leds op 0F en 06 al te pinken, haal ik bv schakelaar 58 of 44 even uit de lus dan lijkt het of het probleem minder groot is, althans in het gebruik merk je geen probleem meer, echter wel het uitlezen van alles in velbusLink blijft identiek.

Eens specifiek logs op één voorbeeld eruit gehaald, schakelaar met adres 06:

  1. lees actie 06 mislukt lees-actie-adres06.log (612 Bytes)

  2. schrijf actie 06(alles, niet enkel wijzigingen) 06 mislukt schrijf-actie-adres06-retry2keer.log (2.8 KB)

  3. schrijf actief 06 (enkel wijzigingen) lukt wel schrijf-actie-enkel-wijzigingen-adres6.log (2.4 KB)

  4. memory debug adres 06 memorydebug_adresknop06.csv (92.2 KB)

  5. simpele scan bus in de software zonder problemen : scan_modules_canbus.log (18.6 KB)

Stel dat de conclusie een bekabelingsprobleem is, waar begin ik best alles te demonteren? Of kan je geen logica vinden? Kan toch niets met voeding zijn? Volgens de manual zouden de leds dan anders flashen (dat doen ze niet…)

Heb nog een homeserver van Stijnen in de doos zitten, kan ik daar iets meer van debugging mee doen? Heb hem met opzet nog niet aangezet zolang dit probleem niet verholpen is.

6

Terminators en topologie lijken in orde.
Aan de logs te zien (tenzij je deze gefilterd hebt op module?) komt er niets tussen dat de communicatie zou verstoren, maar antwoordt de module gewoon niet meer vanaf een bepaald moment.
Dit zou er eerder op wijzen dat de modules zelf een bepaald probleem hebben (wegens mislukte firmware upgrades?).
Vandaar het eerder gegeven advies: de probleemmodules eruit halen, en één voor één in een testopstelling scannen en firmware upgrade doen (of in geval er al de laatste FW inzit, deze nog eens opnieuw “upgraden”, dit gaat dezelfde versie er opnieuw inschrijven).

Eens zeker is dat de modules allemaal correct werken (individueel dan), deze terug plaatsen. Zijn er dan nog problemen, dan lijkt het eerder een bekabelingsprobleem.

Om bekabelingsproblemen op te sporen, is het meestal zaak om deel per deel te isoleren, kijken of er een probleem is per deel, en dan geleidelijk aan de installatie terug opbouwen en telkens kijken of het geheel nog correct werkt.

7

Neen, logs waren niet gefilterd, clear gedaan ervoor en dan export erna zodat je geen overkill log file zou hebben.

Ik heb slechts op 1 module een firmware versie gedaan voor de eerste keer dit weekend, reden hiervoor was net de basis van dit probleem omdat er 1 knop op een oudere build stond.
Ervoor heb ik nooit met firmware’s gespeeld.

Los daarvan kan er wel een toestel tussen zitten met een slechte firmware of waar er ergens iets corrupt is geraakt misschien. Zal eerst dat nog een proberen en een test opstelling maken.

8

Uiteindelijk was het iets stoms, telkens focus op communicatie problemen maar uiteindelijk eens toer gedaan met simpele multimeter en bleek dat op UTP toch meer spanningsval zat dan gedacht.

Op bepaald punt hadden we maar +/- 8V meer, alles bleef normaal werken (ook de knoppen) maar communicatie issues in de software.
Kring daar geknipt en spanning van 2 kanten op de kring ==> probleem opgelost, plaats van de knip komt van 2 kanten nog minimum 12V.

Zou bij nieuwe installatie geen UTP meer gebruiken denk ik, ofwel minder lange kring maken.
Nogthans cat 6 genomen en een getwist paar voor negatief en getwist paar voor positieve spanning genomen.

9

Goed om weten, bedankt om de oplossing te melden.

Waren er geen meldingen op de modules die te weinig spanning kregen? Knipperende LEDs, of de voedingsLED die niet brandde?

10

Neen, niets van meldingen of diagnose leds die opvielen.
Alles werkte normaal, vandaar dat het zo lang duurde tot we daarop uitkwamen.