AEON Lab Multisensor 6 is loosing contact to FBHC 2

[Obiwan1968 0]

I am using some AEON Lab Multisensor 6 with FBHC 2, before with v4.100 now with v4.104B.

 

The FBHC2 is loosing the contact to those devices and they get marked as "dead device". This independend of the distance to the FBHC2, this is from 2m upto 10m, all the same.

 

I can only solve the problem in opening the module, take the batteries out and put them in again, within seconds the module is online again.

 

I have various devices, but this type is the only one making such problems.

 

Anyone having an idea what the problem could be?

 

Thanks!

[mikro 0]

I have the same problem with my AEON 4-in-1. However, I have two such sensors and one works OK.

The problems started on soft 102 and continue on 104

 

Any suggestion how to fix it ???

Thanks in advace

 

[Mo19 1]

I can report that i tested 2 AEOTEC Multisensor 6 but with a 5v power supply using its micro usb cable that only 1 of those 2 is doing the same - loosing connection from time to time, but since it is not battery powered after a few seconds it seems that HCL (in that case) is trying to reconnect and even if the X mark is on the device it polls the device and it continues to work... Strange bug i should say but it works.

[TRicky 84]

Since a while I'm having the same effect with my Aeon 4in1 sensors. Some of them work flawlessly and others loose contact quit frequently.

All off them rum usb power.

I can't tell on what version it started, now I'm still running 4.100

[petergebruers 1,265]

• If you change power supply type, you *must* exclude and include the device. If you don't, both the device and the HC still think it's on the older type of supply. If you are using a USB supply, and still see a battery symbol, you haven't done this. If you don't follow my rule, the device simply thinks it has a big battery. It does not, for instance reinforce your mesh network. It still applies the same rules (in the case of a MS6: they are quite different!) for sending updates.
• The "X" mark does not in any test communication with a battery operated device (please also apply my first rule!) - not sure about mains powered devices.. You cannot test communication because the device is in deep sleep and cannot, does not, respond to commands. The "dead" indication appears if a device failed communications, or the HC did not hear from a battery operated device for a (very) long time. I don't know the exact timing, never asked and never saw published that info here. So "connection to an as-dead-marked battery device" is not really describing what is happening. When you do that, you merely reset a flag that indicates it's dead. Because the GUI changes after you do this, you might think you've solved a problem, but you haven't. If you want to test this: pull the batteries from a MS (so it can't send a low battery warning and becomes effectively dead). Wait 24 h. I't ll be "dead". Click on it, it becomes "alive". But that can't be true, can it?
• The fibaro Swipe is an exception: it is always "battery operated". That's the only exception that I know of. Detection of gestures *does* depend on power source and changes automatically with a worst case 4 minute delay.

[petergebruers 1,265]

I'dd like to add: I *think* a battery operated device can become marked dead if it has an unusually high wake up time. Wake up time of my devices ranges from 600 right up to 86400 (1 day). Most are between 1 and 12 hours. I'm not sure if that causes issues. I'd set the wake up to the manufacturer default to rule that out.

 

In case of MS6: many issue were ironed out in 1.06 and 1.07 firmware. But high battery drain in some circumstances (drains batteries in a few weeks) still exists in all these, right up to 1.08.

[Obiwan1968 0]

Also after upgrade to v4.110 nothing changed. I still have firmware v1.7 in place.

[petergebruers 1,265]

I doubt it is a HC2 firmware issue. I haven't seen reports form other users regarding dead devices lately... I'd do a "Mesh network reconfiguration". You could try an entire network reconfiguration at once. Let it run for at least 1/2 hour. Then wake up your battery powered devices. Observe the status messages. If you want to have a better idea of what's happening, do a device by device update, not an entire net update. Start with mains operated devices.

[chaicka 195]

Perhaps to share some recent experience I had with one of the MS6 and some observations I have on how MS6 behaves with in battery-operated mode.

 

After updating HC2 to 4.110, one of the MS6 further away from the HC2 had turn 'dead node' twice over span of 2 days during business hours when I was away. On both occasions, all I need to do was wake it up and it works fine again. But on the 2nd wake up, I did something extra - manual update the z-wave network for this MS6 and its surrounding mains-powered devices (Fibaro Relays), one by one. Since then, no further 'dead node' occurrence.

 

Over the last year after I managed to get my hands on MS6, I observed two things about it when running as battery-powered:

• Occasionally, it may turn 'dead node' when one out of two of its batteries run flat. Not always the case but somehow, on some rare occasions, it does. I makes me wonder how the device itself switch between the two batteries (since I believe Peter has proven they are not designed to run in parallel).
• On random occasions where the Home Center is rebooted (such as update Home Center software version or reboot of Home Center to flush some abnormalities), there is a tiny chance of somehow the MS6 will start this turning 'dead node' trend. For me, if it turns 'dead node' twice consecutively within a short span (say few days up to a week), I will normally wake it up as near to the spot it is supposed to be, then go and trigger the z-wave network refresh/update for it (of coz need to manual wake up again as soon as toggle in the HC interface) and its nearby mains-powered devices. Usually this fix the turning 'dead node' issue.

Sadly, I do not have the in-depth knowledge of how this device is designed and how the underlying z-wave layer is behaving (since Fibaro has no means to expose the z-wave layer traffic logs unlike some other z-wave gateways/devices), I can only share my experience so far and what I did to workaround the issue. No permanent fix yet but the workarounds seem to have been able to give me a more dependable setup to use. So far the longest period without such hiccups is approx. 3 months until the batteries ran flat.

[AutoFrank 372]

3 hours ago, chaicka said:

Perhaps to share some recent experience I had with one of the MS6 and some observations I have on how MS6 behaves with in battery-operated mode.

 

After updating HC2 to 4.110, one of the MS6 further away from the HC2 had turn 'dead node' twice over span of 2 days during business hours when I was away. On both occasions, all I need to do was wake it up and it works fine again. But on the 2nd wake up, I did something extra - manual update the z-wave network for this MS6 and its surrounding mains-powered devices (Fibaro Relays), one by one. Since then, no further 'dead node' occurrence.

 

Over the last year after I managed to get my hands on MS6, I observed two things about it when running as battery-powered:

• Occasionally, it may turn 'dead node' when one out of two of its batteries run flat. Not always the case but somehow, on some rare occasions, it does. I makes me wonder how the device itself switch between the two batteries (since I believe Peter has proven they are not designed to run in parallel).
• On random occasions where the Home Center is rebooted (such as update Home Center software version or reboot of Home Center to flush some abnormalities), there is a tiny chance of somehow the MS6 will start this turning 'dead node' trend. For me, if it turns 'dead node' twice consecutively within a short span (say few days up to a week), I will normally wake it up as near to the spot it is supposed to be, then go and trigger the z-wave network refresh/update for it (of coz need to manual wake up again as soon as toggle in the HC interface) and its nearby mains-powered devices. Usually this fix the turning 'dead node' issue.

Sadly, I do not have the in-depth knowledge of how this device is designed and how the underlying z-wave layer is behaving (since Fibaro has no means to expose the z-wave layer traffic logs unlike some other z-wave gateways/devices), I can only share my experience so far and what I did to workaround the issue. No permanent fix yet but the workarounds seem to have been able to give me a more dependable setup to use. So far the longest period without such hiccups is approx. 3 months until the batteries ran flat.

 

Thnaks @chaicka

thanks for this. I am in the process of installing 14 of these around the house. I'm hoping to have them all run on usb power. I'm trying to have nothing in the house run on batteries apart from 1 door Fibaro sensor I use for under the stairs. It should be interesting to see if any of mine exhibit any of the behaviour you describe above even though they will be USB powered.

 

I have two sensors that are meant to be battery powered but I have them powered from a 5v supply as they are at outside temp and the batteries weren't lasting at all. As expected the fen though they are ' mains powered' they still behave like a battery device as expected.

 

i wonder for a device like the aeon ms6 that can be natively powered by either battery or USB whether it exhibits different behaviours/settings in both power supply modes or whether it is simply a power supply difference. I doubt it acts as a repeater but I wonder if it goes 'z-wave dead' whether it will need a 'wake-up' to be soft reconfigured or if the parameters  are setup differently if it is included under USB power v battery power. 

 

As an aside i'm using the aeon recessors as most of mine are ceiling mounted and even thoug they are a bit pricey they are a very slick solution. ...

 

[petergebruers 1,265]

3 minutes ago, AutoFrank said:

i wonder for a device like the aeon ms6 that can be natively powered by either battery or USB whether it exhibits different behaviours/settings in both power supply modes or whether it is simply a power supply difference.

 

 

Ah! I'd say, when correctly included, devices that can be battery powered act COMPLETELY different if you include them on USB power. For instance, battery operated devices, on battery, cannot repeat messages, because they cannot *receive* messages in the first place (they sleep)! All MultiSensors, included on USB power, become repeaters. Also, Almost all timing in the sensor is different, again, to conserve battery. So USB will give faster sensor updates, faster motion detection, even different parameters apply... A Fibaro Swipe has different operating modes and gesture detection is fastest and most accurate on USB power (but some supplies interfere and give the opposite result.). But this device is an exception to the rule: it never repeats messages and you can switch power mode at any time, without excluding the device! If you have a battery powered MultiSensor 6 and you connect it to USB, it will behave like a battery device, but with infinite lasting batteries. It is far from optimal. BTW the MS6 tells you how it is working, by sending Parameter 9 to the HC2, visible in the status window. Going by the number of posts on this forum and other forums, the MS6 is a nice sensor if you start and keep running on USB power. There are, however, many, many questions regarding accuracy, reporting and battery life if you included it as a battery device. I have one, on batteries, just for fun. I do all kinds of tests on this device. Oh, yet one more thing. Depending on the firmware, different settings apply. I have at least 3 different technical documents. They all differ and they all contain errors and are clear as mud. Fibaro has to create a different template for this device for each of the available firmware version. As far as I know, they didn't do that yet and I recommend adding the parameters yourself. For sake of completeness, there is a third Z-Wave device type called FLiRS, fast listening routing slave (a routing slave is NOT a repeater) like door locks and the Remotec IR devices.

[AutoFrank 372]

1 hour ago, petergebruers said:

 

Ah! I'd say, when correctly included, devices that can be battery powered act COMPLETELY different if you include them on USB power. For instance, battery operated devices, on battery, cannot repeat messages, because they cannot *receive* messages in the first place (they sleep)! All MultiSensors, included on USB power, become repeaters. Also, Almost all timing in the sensor is different, again, to conserve battery. So USB will give faster sensor updates, faster motion detection, even different parameters apply... A Fibaro Swipe has different operating modes and gesture detection is fastest and most accurate on USB power (but some supplies interfere and give the opposite result.). But this device is an exception to the rule: it never repeats messages and you can switch power mode at any time, without excluding the device! If you have a battery powered MultiSensor 6 and you connect it to USB, it will behave like a battery device, but with infinite lasting batteries. It is far from optimal. BTW the MS6 tells you how it is working, by sending Parameter 9 to the HC2, visible in the status window. Going by the number of posts on this forum and other forums, the MS6 is a nice sensor if you start and keep running on USB power. There are, however, many, many questions regarding accuracy, reporting and battery life if you included it as a battery device. I have one, on batteries, just for fun. I do all kinds of tests on this device. Oh, yet one more thing. Depending on the firmware, different settings apply. I have at least 3 different technical documents. They all differ and they all contain errors and are clear as mud. Fibaro has to create a different template for this device for each of the available firmware version. As far as I know, they didn't do that yet and I recommend adding the parameters yourself. For sake of completeness, there is a third Z-Wave device type called FLiRS, fast listening routing slave (a routing slave is NOT a repeater) like door locks and the Remotec IR devices.

 

Thanks Peter,

..that makes sense..

I'm including all mine on usb power and must check on the parameters. Do you know where I might find those or will it be a case of search and search like the other z-wave devices?

 

 

[petergebruers 1,265]

Please login or register to see this link.

[chaicka 195]

23 hours ago, AutoFrank said:

 

Thnaks @chaicka

thanks for this. I am in the process of installing 14 of these around the house. I'm hoping to have them all run on usb power. I'm trying to have nothing in the house run on batteries apart from 1 door Fibaro sensor I use for under the stairs. It should be interesting to see if any of mine exhibit any of the behaviour you describe above even though they will be USB powered.

 

I have two sensors that are meant to be battery powered but I have them powered from a 5v supply as they are at outside temp and the batteries weren't lasting at all. As expected the fen though they are ' mains powered' they still behave like a battery device as expected.

 

i wonder for a device like the aeon ms6 that can be natively powered by either battery or USB whether it exhibits different behaviours/settings in both power supply modes or whether it is simply a power supply difference. I doubt it acts as a repeater but I wonder if it goes 'z-wave dead' whether it will need a 'wake-up' to be soft reconfigured or if the parameters  are setup differently if it is included under USB power v battery power. 

 

As an aside i'm using the aeon recessors as most of mine are ceiling mounted and even thoug they are a bit pricey they are a very slick solution. ...

 

 

Both MS6 I have are installed with recessors on false ceilings.

 

Too bad Fibaro did not offer similar recessor for ceiling flush mounting of FGMS.

Edited January 9, 2017 by chaicka

[Mo19 1]

Hi guys,

 

I want to report the following problem. I have 2 AEOTEC Multisensors 6 both USB powered and 1 of them is just fine, but the other frequently looses contact with HC2 and after a few seconds it reconnects with it and everything is fine. BUT, those losses of communication lead to readings like 1000 humidity and 200 degrees C that is OUT OF THIS WORLD! After a few seconds it is polled again and this time reports normal temp, but that repeats from 4 to 6 hours and sends me emails and push mesages that is frustrating and annoying. Any suggestions what the cause might be?

[chaicka 195]

7 minutes ago, Mo19 said:

Hi guys,

 

I want to report the following problem. I have 2 AEOTEC Multisensors 6 both USB powered and 1 of them is just fine, but the other frequently looses contact with HC2 and after a few seconds it reconnects with it and everything is fine. BUT, those losses of communication lead to readings like 1000 humidity and 200 degrees C that is OUT OF THIS WORLD! After a few seconds it is polled again and this time reports normal temp, but that repeats from 4 to 6 hours and sends me emails and push mesages that is frustrating and annoying. Any suggestions what the cause might be?

 

• Is the misbehaving MS6 included in secure mode or non-secure mode?
• How is the distance from HC (this related to the above)?
• Tried to rebuild the z-wave mesh of the device and its surrounding mains-powered devices? (use targetted approach - one at a time and circle back if needed, not mass z-wave network rebuild approach as it does not really ends well)

[Mo19 1]

• the misbehaving MS6 included in secure mode or non-secure mode?
• How is the distance from HC (this related to the above)?
• Tried to rebuild the z-wave mesh of the device and its surrounding mains-powered devices? (use targetted approach - one at a time and circle back if needed, not mass z-wave network rebuild approach as it does not really ends well)

It is in secure mode (as far as i can remember)

It is like 2-3 meter away from the HC2

And yes, i tried to rebuild the mesh network asking the surrounding relays to give the controller their position and surrounding devices

[Mo19 1]

And parameter 41 show AMAZING numbers - this parameter is for temp calibration/treshold but in HC2 and Lite it shows HUGE number even after i change it and save it.....

[chaicka 195]

4 minutes ago, Mo19 said:

And parameter 41 show AMAZING numbers - this parameter is for temp calibration/treshold but in HC2 and Lite it shows HUGE number even after i change it and save it.....

 

Known issue. Search the forum on a thread discussing this. It is due to Aeotec changing that parameter to 3-bytes instead of 2-bytes in firmware 1.07 (aka 1.7 in Home Center GUI). It is calibration, not threshold.

 

Aeotec reverts it back to 2-bytes in beta 1.08 firmware.

Edited January 13, 2017 by chaicka

[chaicka 195]

7 minutes ago, Mo19 said:

• the misbehaving MS6 included in secure mode or non-secure mode?
• How is the distance from HC (this related to the above)?
• Tried to rebuild the z-wave mesh of the device and its surrounding mains-powered devices? (use targetted approach - one at a time and circle back if needed, not mass z-wave network rebuild approach as it does not really ends well)

It is in secure mode (as far as i can remember)

It is like 2-3 meter away from the HC2

And yes, i tried to rebuild the mesh network asking the surrounding relays to give the controller their position and surrounding devices

 

You may not like this. Try the same but in non-secure mode and see if it works better.

[Mo19 1]

is it because the firmware of the product or something else? What is the problem then?

I will try with non secure mode, but the interesting part is that the sensor trigered alarm scene after it was included and the lights at my home started to go crazy... The other sensor did not do that? Any explanation?