Strange phenomenon in my installation, Some lights in the house switch automatically on, no need to tell you this is annoying during the night
Problem became more obvious after installing a VMBPIRO. Which is disconnected again, but the problem persists, so it surely activated something.
Already trying for 5 days to pinpoint the reason of this, but running out of options and could use some fresh ideas.
Let me go in detail for a particular room:
CH1 - VMB4RYLD ch2
CH2 - VMBDMI
CH3 - not configured
CH4 - not configured
CH1 - VMBDMI
CH2 - VMB4RYLD ch2
CH1 - VMBDMI
CH2 - VMB4RYLD ch2
What happens, randomly mostly during the night the light switches on (doesn’t go off, so only activated), we can hear the click in the switch when a light goes on. If we switch off manually, it goes on again after a few seconds. We have switch it off several times before it stops…
This is what we discovered so far:
CH1 - VMBDMI activated automatically with click noise
CH2 - VMB4RYLD
CH1 - VMB4RYLD activated automatically with click noise
CH2 - VMBDMI
There are no timers, neither calenders configured.
What did i do so far:
Disconnected the VMBPIRO (completely, so no power or bus connection). My initial thought this was disturbing the BUS…
Disconnected Home Center (maybe this was overloading the bus after a soft update)
Switched off/on the velbus power supply
Rewrite (changes) the configuration to all the modules, the light points i have issues with are on different modules (different relais modules, dimmer).
Latest change was change the reaction time to one second of the VMBGP2, saved this all to a new project file.
rewrite (complete) the config to all the modules
Added an extra power supply, which is feeding first floor + attic
Any idea’s, suggestion experience?
(now that i’m writing this, i get the idea that the light points that have this phenomenon are switched by a VMBGP2. Maybe this is the direction to focus on?)
Thanks for the help on brainstorming.
Normally cabling problem could be ruled out… all the wires are twisted and screwed tightly in the plug’s (as i might speak for myself, this is done like a school example). Unless there is a cable fault… but for this reason i’ve created a ring BUS on each floor so more or less a redundant solution. Since the problems occurs on each floor… although my installation has a star connection as well, i’ve placed an bus cable outside to the garden house where a relais and vmbpiro are connected and a second ‘line’ to the attic. The lights in the garden house are the device on the attic are uninfected with the current issue.
But the temperature thing does ring a bell. Did a recent change on the addressing of the temp sensors, in fact i wanted to disable some, because it has no sense measruring three times in one room… so i’ve placed the address of that sensor on 255… thinking this is the way to disable them, is this wrong?
Furthermore, i have the velbuslink software running with the logging function on. Despite the fact that i disabled sending automtic temp changes over the bus, i see them passing by there…? I’ll dig in to this…
EDIT: See in image below there is no address set for temperature, but they are showing up in the log…? Or is the thermostat address only required if you actually control the heating? (but then it wouldn’t explain why i have so less temperautes coming in the log). Getting confused here http://s28.postimg.org/5yca80d4t/velbus_address.jpg
Sorry for the delay, I got caught up in designing a poster and forgot to reply to you.
So, first things first.
Yes, setting the thermostat feature of glass panels to address 255 or FF will disable the button command function, but as you’ve noticed it doesn’t stop the panel sending the temperature data.
This is sent from the panel’s base address.
(Useful to remember when configuring the graphing app)
If you want to stop the data bring sent, you need to configure the module, select thermostat and advanced features.
In the right hand panel you’ll see the section that gives 3 options for when the data is transmitted.
When it changes,
Every X seconds (up to 255 seconds)
The next thing to do is find out what’s causing the glass panel to leave a noise.
This is what is concerning me the most.
A complete re-write should resolve any base conflicts.
One issue I did have with an installation was a bouncing packet of data due to a terminator issue.
You say that you’ve removed a PIR, could this have anything to do with it?
Temp data sending is sorted out now. (and as we speak, i’m on the graphic app, figuring out how it works, i’ll come back to this in the active thread)
The PIR was removed, because i believed this was causing the problem, now it seems it wasn’t so i can connect that one again.
For a temporary workaround i’ve activated a delay of 1 second to the VMBGP2.
Didn’t have any new disturbances up to now. Maybe this has to do also with a re-write to the panels…? I’ll wait a couple of days and switch back to direct action of the panels.
Had this idea as well, but couldn’t find any obvious appliance… the bus cable is separated from power cables, only in the junction box they pass together.
Installation is running for +/- 6 months, hadn’t have any issue’s. My guess it that it has to do with something that went wrong with writing to the modules? Problem came after modifying the configuration for the pir…
After putting a delay on the switches, the problem didn’t occur anymore. Will change it back to direct and see what happens.
Glass panels triggering themselves is rare and can be difficult to trace, as so many parameters can be an influence. Here are some general ideas, maybe some of them can be of help…
do you have the right amount of terminators set in the right places? In almost all cases, two terminators as far as possible from each other, is ideal.
do you use the latest Velbuslink version? Using newer hardware with older versions of Velbuslink can cause problems. See also next point.
in case the problems might be related to what’s written into the modules, make sure you use the latest Velbuslink version (see above). Then try doing a full write (sync -> untick “write only changes”) of problematic modules, and/or the whole system. If the problem persists, you can try resetting modules to factory defaults (the little brush icon) and then doing a write. This deletes actions in the module, so you’ll have to redefine them. If this still doesn’t help, see if you can do a firmware upgrade (rightclick on the module -> firmware upgrade). This doen not delete actions. After the upgrade, do a full write to the module, nothing will be lost.
sometimes a problem (eg. a faulty contact) may have existed for a longer time, but the system coped with it, so it was not noticeable. When adding modules or changing configs, this problem can suddenly surface. One then thinks the problem is related to the latest change, which is not always the case, especially in case of cable problems. The vast majority of problems in Velbus installations are simply due to cable problems.
More specifically concerning glass panels that trigger automatically. Things to consider are:
presence of PWM dimmers or discharge lamps in the vicinity
what kind of cable is used over which distances? Different types of cables allow for different distances and may be more or less susceptible to interference etc.
what kind of power supply do you use? If you don’t use the VMBSMPS, your power supply may have a ripple that can trigger the glass panels.
to trace the cause of the auto-trigger, is there anything that turns off or on at the same time? At night, maybe an electric boiler, …? Sudden changes in humidity and other atmospheric conditions might be related.
terminator is placed on the line going outside the house on a VMB8PB and on the PIR (which is disconnected for the moment)
Yes, I’m keeping this up-to-date
indeed, suppose the error was caused here, because I’ve changed the reaction time to 1 second, Installation was fine again, tested for 3 days. Changed it back to direct action, had no disturbance (yet). Although it is very strange only the VMBGP2 where ‘infected’.
All EIB cable (seperate preflex), all connection points are twisted to ensure good contacts. Concerning the cable lenghts, think the longest point will be at 25 meters… in total I’ve used +/-200 meters.
1x VMBSMPS (but i have to admit was reaching the limit with 95 units, after the problem started i have been merging my spare parts in the installation, now i’m exceeding the max)
No boiler in the house, only thinking about the day/night pulse from the utility… but this is far-fetched i guess. since this is on a fixed time… lights when on randomly.
Anyway, installation seems to work fine again, i’ll keep you posted when the phenomenon returns
Thanks for the help, I’ve learned a lot.
You mentioned that one terminator is set on the VMBPIRO, which is now disconnected. Does this mean you only have one terminator left? In that case, you’ll need to set another terminator.
You might also experiment with one extra terminator, in large or complex installations sometimes three terminators work better.