Fibaro 3 in 1 Sensor Ghost devices keep appearing

Other Devices & Integrations Door Locks & Sensors
#20

yes nice take on it :wink: shame Vera didn’t realise what they had done coz they opened a support ticket when it was first notified to them by several users :wink:

#21

Dear Mr Vera. Please may we have a fix for this?@
…or at least tell us how to delete the phantom with deleting ‘real devices’.

#22

Mmm, I thought I had posted a work around for this, just change the parent device to accept child devices in a different room, then set the ghost device to a newly created Room called Zwave at least it then sits at the bottom, out of sight out of mind :wink:

Sure we will get a proper fix soon, along with battery level fix :wink:

#23

Hello Vera :wink:

Any news?

#24

Hello Vera any news…

#25

Read next 3 posts from bottom to this top.

Vera, how about this? Though I do not have this fibaro PITA device anymore and changed it for a bigger PITA device the Aeotec multisensor 6in1 which should be supported by Vera.

Below the support communication which I tried to delete the kindnesses like “hello and goodbye” for the sake of readability. I am pretty frustrated due to the fact Vera worked “well” for a few years and since the latest firmware update I have these ghost devices and can’t detect devices a LOT.

BODY IS LIMITED TO 320000 characters so in 2 parts: 1/2

Hello?

I have 2 new ghost devices again yesterday:

#0-1212

time_created

2019-10-06T07:50:48

#0-1213

time_created

2019-10-06T07:50:48

When will I receive proper support please?!

I pressed configre now for the 6in1 and SO FR#@@@KING frustrating! All device IDs have changed again!

Hello,

Just today alle ghost device appeared again. What is causing this behavior? And wh nwill this be solved!?

Also On a running fibaro for years (blind) I had this sudden _ generic deivce ghosts deives… I tried to configure node now but it is now waiting for wakeup.

SO UNRELIABLE!

##- Please type your reply above this line -##

Your request (185865) has been updated. To add additional comments, reply to this email.

Ionut Sinatovici (Vera)

Sep 11, 15:05 UTC

Hello Senders,

Sorry for being slow to get back to you.

We need to find out if the device is sending those fake reports and the engine generates new devices or the engine itself decides.

Did this happen any recent time in the last 6 days? I did go through the logs, but I could not find anything related to those ghost devices appearing.

Thank you. I’m waiting for your reply!

Sender

Sep 2, 14:57 UTC

Hello,

The firmware is the latest:

I can’t do a configure node now every time again, the device is located on the actual position. They keep re-apperaing all the time.

I will enable tech support.

BUT PLEASE DO NOT CHANGE ANYTHING THAT MIGHT GO WRONG!!!

Ionut Sinatovici (Vera)

Sep 2, 14:34 UTC

Hello Sender,

Devices show “Can’t detect device” when Vera cannot properly Poll them or get updates. Even though those devices work, Polling may be disabled or Vera cannot actually poll them.

Also, we’ve might of found a solution for the sensors that show “Can’t detect device” even though they should not show it yet.

Would you please Enable Tech Support so we could try and change the configuration a bit?

Also, ghost devices can be removed through reconfiguration, “Device Menu → Advanced → Commands → Configure Node Right now”, for this process the device needs to be close to the controller as it’s going to remove and re-add child devices. If the device does this on regular basis, it might need a Firmware Upgrade (the device itself).

Thank you. I’m waiting for your reply!

Sender

Sep 2, 06:59 UTC

Hello,

So how can I get rid of the ghost devices now?

And additionally, why is this device showing can’t detect though it does work well (can control via vera).

Ionut Sinatovici (Vera)

Aug 27, 12:44 UTC

Hello Sender,

Not exactly, my previous email addressed a few other devices as well, but the information we have so far is not the best since the “Wake-up fail” count does not reset and does not restart in your case, the device itself fails to report once or twice and the counter does not start from 1 as it should, but goes on from the previous 50 when the device failed to respond.

This is something that should not happen and it’s happening for your Battery Operated devices that you mentioned, the sensors. We’ve been talking with our integration team just to make sure that there is no Device Integration fault so we could check with the other teams as well.

If this is an intended behavior it should be patched so the counter would increase, but the limit would also be raised with +50, so it goes to 100 as the message should only show when the fail counter reaches 50.

I did mention this in my previous email, but it might of seemed related to the one UV sensor alone.

I will be getting back to you with more information related to this issue once we get word from our other teams.

Thank you. Have a good day!

Sender

Aug 22, 16:31 UTC

Thanks for the update.

This answer is specifically for the 6in1 sensor with UV? How about my other issues?

Ionut Sinatovici (Vera)

Aug 22, 15:41 UTC

Hello Sender,

I was out of the office for a small period of time and I did not have access to everything email related.

However, I took the logs from my tests and the logs from your unit and went the whole day through them. The UV sensor still reports low values for myself too, it never went over 2, but I wasn’t able to find out how exactly is the sensor reporting since it only supports 1-7 values as far as we could find.

Regarding the “Cannot detect device” issue, I’m unsure as I never got the same issue, but my testing environment is kind of “ideal” since there are a few devices fairly close to the controller without the ability to route through multiple devices, signal blocks due to walls and so forth.

Then I looked at your logs from 15.08 to 21.08. Starting with the UV sensor, yours mostly reports 0 and 1, but mainly 0, mine was a bit more 1 consistent and kept reporting 1 way more. This might be due to the placement as well as the times it was reporting 1 it was between 11AM - 2PM.

Regarding the “Cannot detect device”, the issue seems to be caused by “Wake up” failing to be fully sent or the device being unresponsive when Vera is asking for information.

By looking at each device in part it seems that sometimes Vera does do an unnecessary thing and calls back the last wake-up which could of been a failed one or skips and then updates the CommFailure variable.

ex: Device_Basic::RateWakeups: there is no wakeup or we check the last one, calculating how many failed j=50, waekupList 50

Then, the next variable updated is the commfailure one: Device_Variable::m_szValue_set device service: urn:micasaverde-com:serviceId:HaDevice1 variable: CommFailure was: 0 now: 1.

The issue seems to be related to the previous fails that get updated even after the device is responsive, we will check with other teams and see if there is something unclear in the logs or the controller does this by itself, devices do not respond, unfortunately we won’t be able to tell through this log, but we can use the log to find the issue and see if it can be fixed.

I will give you an update once I have a response from the integration team mostly as other teams may require a specific task that needs to be checked with integration first.

Apologizes for the lack of assistance with these issues, but I requested my colleagues to leave it as it is until we manage to get results from our side and until we all get to look into the logs and see what we can find.

I hope that our next encounters won’t be this problematic, also I won’t be missing for a long time from now so feedback would be more fluid from now on.

Thank you. Have a good day!

Omar Gonzalez (Vera)

Aug 20, 18:38 UTC

Request #193188 “Re: Re: Battery operated sensors…” was closed and merged into this request. Last comment in request #193188:

And again no reply, please SUPPORT me?!

Onderwerp: Re: Re: Battery operated sensors problem

Hello,

Then please raise my issues to the top support teamt.

Sender

Aug 16, 18:35 UTC

Hello,

Then please raise my issues to the top support teamt.

Sender

Aug 14, 12:41 UTC

What is the status?

The so being called supported 6in1 sensor did create 5 (!) ghost devices. What is happening with my support request?

Please read the below mail from bottom to top and see my frustrations again.

Sender

Aug 6, 19:18 UTC

Ionut,

Thank you for the update. I must say that the support is not what I would expect it to be. If a device is supported by Vera (fibaro motion and smoke e.g.) I expect it to be supported and not to have all kinds of problems of ghosts, can’t detect etc. failures. I have replaced all sensors in their lifetime due to vera support says “the new version has better integration” a quite expensive way of trial on error. But in the end all gets #@$ed up (I may not swear but it is really #@$ed up).

Ionut Sinatovici (Vera)

Aug 6, 15:24 UTC

Hello Sender,

Apologizes for the silence, I was doing some tests and also log checks, to be honest, I’m not having much luck with the sensor too as sometimes it becomes inconsistent.

I did make progress though and managed to get it to report more than 1, but not sure if the result is real as weather wasn’t very favorable and I had to improvise a bit, regardless the sensor will report values between 1 and 7 only, I do not know what exactly each step means and how Vera will decide which value should be displayed.

Regarding the Cant detect device, I am still collecting information from my device here, it didn’t go offline yet, yours did previously due to Wake-up failure.

I will be giving you more updates as soon as I have information that actually helps.

Thank you. Have a good day!

Sender

Aug 2, 16:31 UTC

Ionut,

Onkyo is down intentinally, the rest by error…

Ionut Sinatovici (Vera)

Aug 2, 15:21 UTC

Hello Sender,

Apologizes for the huge delay! I was out of the office for a bit.

I can understand your point and you are right, there are so many things to fix, I can assure you that we are working on every little bit we are given, but sometimes to fix a functionality you have to break something else and we are trying our hard to avoid that, fixing things proves to be way harder than expected due to each device being so different and versatile.

Ghost devices usually appear when the Engine of the unit sees the device as a different Type, assuming a device with 2 child devices, Motion and Temperature, if the Engine somehow detects the Motion Sensor as a different Type it will add a new device with a new ID and category/type as it previously detected. Sometimes the device sends reports and values that are different than before and the engine cannot properly interpret them and changes the type to match its grid.

Sometimes the engine is in a bad state and cannot interpret those values properly and decides that the device behavior does not fit its Type and changes it. We fix this for a huge part of Switches and Sensors that were doing this constantly by adding a specific category and template specific to them and their variations, but there are improvements to come and every device will be fixed as long as the Unit is the issue.

Regarding battery reports, some devices send them regardless of how they were connected, to avoid this, if you have an USB Powered device that will remain like that or you are planning to use it like that, make sure to Add it while on USB so the battery variable won’t get updated as soon as you add it.

Now, for battery operated devices the “Cant detect device” error works a bit different as if the device fails to send a full Wake-up report repeatedly the CommFailure variable will get updated to 1 and the message will show. The generic message should be removed when the sensor wakes-up properly, but we need to see exactly what fail and why so this could get patched as it was previously for other devices.

The UV sensor and the reports it sends was to be tested by myself, but given my unexpected offtime I was actually unable to create a good test case so we could use it between teams and see what goes bad and why does the sensor report faulty if it does. I would like you to consider giving me more time to look into this.

I will get the logs of the past days so we won’t somehow lose them and we will look a bit more into the battery and also cant detect issue, the log from 27.07.2019 and it seems that the sensor had a few failed Wake-up reports and that’s when the “Cant detect message” appeared.

The device reached the maximum Wakeup Fails that it can reach before sending out the “Cant detect device” message, it actually reached 50 fails, later on at the next Wake up call the error cleared itself as the device reported properly. The Wakup time seems to be set to 70 minutes I think, if you can try to increase it to 90 or 120 if 70 is not the default value. Even so it’s not enough to tell what exactly happened as we most likely going to need more time to go through the Z-wave logs and see what exactly failed since the general log only shows a few generic information.

If possible, give us access to the controller one more time so we can have a look at each device’s configuration as it would be much easier through the unit directly.

Thank you. I’m looking forward to your reply!

Sender

Jul 27, 12:57 UTC

Ionut,

Can you see why I am so F#cking frustrated? Every time there is something else. I do EXACTLY what you (vera support) is saying, but evytime another problem arises. Now I have this ghost sensors appearing again. And the 6-in1 sensor is set to auto configure an USB powered. Is this device supported or not!?

Can you remind Melih that he sais “we will support every single device out there” Can you start here?

Sender

Ps. Nothing personal to you.

Sender

Jul 27, 12:52 UTC

Hello Ionut,

I presume you are the next level support engineer and I hope you are able to help me out.

Below problem(s) are not only related to UV.

But toe an overall lack of support for battery operated devices.

I have this problem with a lot of battery operated devices but mainly with the Fibaro smoke sensors and the motion sensors. Of which one of them I replaced by a multisensory (6in1)

I have had SO FREAKING MUCH CONTACT WITH Vera support, I lost count.

I now have 2 errors again:

Battery in smoke is brtand new.

6-in1 is USB powered.

WTF is wrong with it all the time?

Sender

Sender

Jul 25, 10:15 UTC

Hi,

The sensor is outside protected by rain, USB Powered, next to a zwave repeater. Picture provided.

After 2PM the sun reaches the sensor until 8PM.

Ionut Sinatovici (Vera)

Jul 24, 19:52 UTC

Hello Sender,

We checked the Device and we looked into what exactly the device is sending, the device mostly sends 0x0 values, this is within the Vera Logs that we can see, if the device actually sends a different value on a lower level we won’t actually see it through Vera’s logs as this is what Vera receives from the device, as an example please see:

ZWaveNode::HandlePollUpdate node 230 device 1141 class * 0x31 command 0x5 * m_iFrameID 193/19017896 data 0x1b 0x1 0x0 (###)

ZWaveNode::HandlePollUpdate_SensorMultiLevel_MeterReport 0x31 node 230 device 1141 child 230/1165 cat 28 embed: 4 type 27 rate type 0 is 0.000000 was 0.000000 prec 0 sca 0 size 1 delta -1 previous -1.000000 len 3

This is the update that the sensor sends, I’m not sure where exactly is the sensor placed and what exactly is it picking up. We will check with our other teams from Testing and Integration to make sure that we are interpreting this right or maybe they have extra info that we could use in this case to make sure that we get accurate reports from the UV sensor.

I will be giving you an update on this in a bit as we need to further investigate and also get more information from our colleagues.

Thank you. Have a good day!

Sender

Jul 23, 18:01 UTC

Bogdan,

Can you please escalate this case to a higher tier?

Next things are NOT personal:

$%#^#$%^$%^$%!

I changed the multisensory to “autoconfigure” yes and now everything changed again. For @##@#@#@!

I tried after 1 hour to “configure node now”, but now it hangs at purging associations for 6 hours.

Is this devices supported? I remember very well that Melih told the community to support every single device out there. According to the compatibility list this sensor should be supported. I traded in this sensor with a Fibaro that was having the exact same symptoms.

You must know I may not swear, but for F#CKSAKE this drives me crazy!

Every single time something else is broken or not functioning.

Can you please as Vera help me out of this mess?

Sender

Jul 23, 06:48 UTC

Hello,

I did NOT make any changes to the device after setting to automatically configure no.

I never included with batteries.

I still do not see the UV values updated.

Can you see why this is so hard?

Bogdan M. (Vera)

Jul 23, 06:32 UTC

Hello Sender,

The “_GET_LANG(generic_sensor)” devices are created if you’re trying to change parameters on a device while it’s set on “Automatically Configure: NO”.

You’ll have to set it back to “Automatically Configure: Yes/Default” and re-configure the device in order to have those child devices disappear.

In regards to the battery: if during the inclusion the device was powered by batteries, it gets configured as a battery powered device. The battery icon will not disappear when you then connect the USB cable.
You have to include it while on the wired connection in order to not have the battery icon generated initially.

Have a nice day.

Sender

Jul 20, 18:27 UTC

They’re in Vera too… what is causing this?

Bogdan,

Thanks for that.

I just placed the 6-in-1 motion sensor to outside. It reports motion. But in Altui and in Imperihome I have all kinds of ghost devices. The device is set to “do not configure automatically” by me directly after successful inclusion.

What’s wrong now again? Can you see why I am so frustrated with this?

Sender

Jul 20, 13:46 UTC

The’re in Vera too… what is causing this?

Bogdan,

Thanks for that.

I just placed the 6-in-1 motion sensor to outside. It reports motion. But in Altui and in Imperihome I have all kinds of ghost devices. The device is set to “do not configure automatically” by me directly after successful inclusion.

What’s wrong now again? Can you see why I am so frustrated with this?

Sender

Jul 20, 13:32 UTC

And the device is not battery powered, but USB powered… I can see a battery logo and the wakeup is 1800? That is not ok according to me. How can I change that?

I have set parameter 111 to 30 seconds:

Bogdan,

Thanks for that.

I just placed the 6-in-1 motion sensor to outside. It reports motion. But in Altui and in Imperihome I have all kinds of ghost devices. The device is set to “do not configure automatically” by me directly after successful inclusion.

What’s wrong now again? Can you see why I am so frustrated with this?

Regards,

Sender

Sender

Jul 20, 13:26 UTC

Bogdan,

Thanks for that.

I just placed the 6-in-1 motion sensor to outside. It reports motion. But in Altui and in Imperihome I have all kinds of ghost devices. The device is set to “do not configure automatically” by me directly after successful inclusion.

What’s wrong now again? Can you see why I am so frustrated with this?

Regards,

Sender

Bogdan M. (Vera)

Jul 19, 19:13 UTC

Hello Sender,

I’ve removed the message from device #1118.
Also removed from the interface device #1153 which was created by device #1025.

The Aeotec Multisensor is no longer displaying the “Can’t detect message”. For wired devices the message is generated if they fail to respond to a number of polls.

The controller seems to be functioning correctly at the moment.
Please check it from your end and let me know if I can be of further assistance.

Sender

Jul 19, 18:41 UTC

Bogdan,

My whole zwave network is now instable!

Nothing works as it should.

What is going on?

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Problem 3.

Device 1118 has fresh batteries, a shows Can’t detect device.

I woke it manually, tried everything and Vera just lost it again.

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Can you see what I mean? There is always something with this sytem… And I can’t “solve” it myself else then exclude include and put a freaking lot of time and effort in it.

Bogdan,

Problem 2 just appeared.

Out of nothing a ghost device is appeared:

device #1153

What is this?

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Bogdan,

I am back at the beginning again.

The main reason for opening this mail thread which is QUITE LONG now.

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

All logging is still maximal and the newly added sensor (Multisensor 6 in 1 – Device 1141) is again having Can’t Detect Device

It’s getting pretty annoying that it always seems there is something wrong with my Vera.

Can you assist me what this is again?

The sensor is USB powered.

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Sender

Jul 19, 18:12 UTC

Bogdan,

Problem 2 just appeared.

Out of nothing a ghost device is appeared:

device #1153

What is this?

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Bogdan,

I am back at the beginning again.

The main reason for opening this mail thread which is QUITE LONG now.

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

All logging is still maximal and the newly added sensor (Multisensor 6 in 1 – Device 1141) is again having Can’t Detect Device

It’s getting pretty annoying that it always seems there is something wrong with my Vera.

Can you assist me what this is again?

The sensor is USB powered.

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Vera Support Created a Mess - Help!
#26

Part 2/3:

Sender

Jul 19, 18:03 UTC

Bogdan,

I am back at the beginning again.

The main reason for opening this mail thread which is QUITE LONG now.

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

All logging is still maximal and the newly added sensor (Multisensor 6 in 1 – Device 1141) is again having Can’t Detect Device

It’s getting pretty annoying that it always seems there is something wrong with my Vera.

Can you assist me what this is again?

The sensor is USB powered.

Remote Access

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Regards,

Sender

Sender

Jul 19, 17:06 UTC

I did not touch the sensor…

Bogdan M. (Vera)

Jul 19, 14:39 UTC

Hello Sender,

The tamper alerts are generated by the sensor whenever you remove the battery cover.

Have a nice day.

Sender

Jul 19, 09:08 UTC

Hello Bogdan,

I have received a replacement for the AEOTEC MultiSensor 6-in-1. I is included again.

I have externally upgraded firmware to version 1.13 again.

I have now powered via USB and not batteries (so parameter 101 is 240 now on advice of AEOTEC). Although battery icon keeps showing in Vera’s interface.

Added the following parameters again:

Until now the sensor is inside and not reporting any UV. I will mount it outside tomorrow when I receive a longer USB cable for external power.

What I see I that there are “tampering alerts”, what are those?

Will keep you updated.

Bogdan M. (Vera)

Jul 5, 18:36 UTC

Hello Sender,

Please find my answers below.

  1. We cannot manually disable that message. It’s a function of the engine that cannot be adjusted for a specific device.
    The only possible workaround was to manually set the “Configured” variable to “0” but we already tried that and it didn’t work.

  2. I’m not sure if those parameters help in this specific case but from what I can see it stays untripped at the moment.

  3. I was referring to the “Voordeur Camera” which seems to be the only one included on the controller.
    I meant to type scene #53 there. Sorry about the typo.

Have a nice day.

Sender

Jul 5, 06:50 UTC

Hello, see below in line in green.

And thank you for this reply. I have tried a few things. Let’s hope it gets better. Please reply on my questions.

Regards,

Sender

Attachment(s)
image001.jpg

Bogdan M. (Vera)

Jul 4, 21:29 UTC

Hello Sender,

  1. The Aeotec ZW100 Multisensor is supported. However, in this case, the device might be defective.

I’ve checked the logs for a few days and it does report the UV but it’s always 0.

As for the LUX values, to give you an example, on a full day (July 1st) it started reporting a value other than 0 at 11:55:20.

  • It then kept reporting a few similar values for a couple of hours
  • then at 14:55:20 it reported 0 for some reason.
  • at 15:25:21 it started reporting again values higher than 0.
  • at 17:25:21 it reported 0 and kept reporting 0 for the rest of the day.

There’s nothing else we can do if the device doesn’t report something other than 0.

  1. The “Wall-C scene controller” is still not fully configured because it doesn’t report the complete information that the controller needs in order to finish it’s configuration. This is why the message is displayed. Since the device is functioning and the previous workarounds didn’t work I’d recommend you to leave it as is.

  2. The “Tripped” variable is updated based on the reports from the sensors.
    Device #737 reported being tripped at one point and never reported being untripped. Thus the Vera didn’t change its status.
    Device #986 is constantly reporting the tripped status, never untripped.

  3. The smoke sensor (device #911) was indeed tripped on 06/30/19 at 23:38:56.603. However the engine crashed after that. From what I can see in the logs there are a couple of possible causes:

  • the crash seems to have occurred immediately after the recording was started on the camera
  • the other cause could actually be the scene that should’ve ran (ID #53)

I would recommend you to do a couple of tests in order to see if the issue reoccurs:

  • one test would be to deactivate the camera recording in home mode and then trigger the scene.
    To do this you have to go to Dashboard → My Modes → under “What to do if an armed sensor trips” disable the camera recording.

  • the other test would involve editing the scene (#52) in a few ways. Try removing the Luup code and test the behavior. Another test would be to split the actions on Step 2 into 2 or 3 groups separated by a few seconds of delay.

Let me know how it goes.

Sender

Jul 3, 07:10 UTC

Hello,

Any update on below?

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Hello,

We are back to the beginning again. And I have added an extra problem (number 4):

  1. MultiSensorn 6-in-1

The values never update in the user interface. Cool you see it in the logs but that does not help me. The sensor is placed outside and the weather is pretty UV good. LUX and UV are always 0.

This is till an issue, depite some thing you mailed before. Only 2 moments the value was “updated” but this is not normal:

Why is this not updating? Why is UV never updating? Please tell me that this device is compatible with Vera?!

  1. Wall-C scene controller not configured always

We mailed a lot about it, but the problem is the same now as initially. Device works, but Red line with “Waiting for wakeup to configure device”.

  1. Motion Sensors stay tripped without motion.

Device #0-737 and #0-986 Now are when there is no motion (737 doesn’ even has input!).

  1. Fibarop smoke sensor #0-911 detected ( false , but nevertheless ) smoke yesterday evening!

It did trigger Vera due to there is logging… I have “a scene ID53, which should trigger:

BUT NOTHING HAPPENED!

  1. All other below problems I have solved by (AGAIN) deleting the device from Vera and adding it back) and then after a while I am stuck with the same problem again.

Support is re-enabled again:

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Sender

Jul 1, 07:09 UTC

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS **

Sender

Jun 29, 11:49 UTC

Did something, don’t know what: but I switch to auto configure yes, then woke up device – configure node now and then it started to function again.

In order to avoid the red line (initial problem!) I immediately changed to “do not auto configure” and the red line is back…

At least it is now functioning again but with an annoying red line.

Hello,

Long story, tried it again. Also with “automatically configure” to ON. But nothing helps.

What I don’t get is that it worked for YEARS!

Sender

Jun 29, 11:44 UTC

Hello,

Lomg story, tried it agasin. Also with “automatically configure” to ON. But nothing helps.

What I don’t get is that it worked for YEARS!

Bogdan M. (Vera)

Jun 28, 11:23 UTC

Hello Sender,

Device #785 did report the “ManufacturerInfo” and is configured correctly which is why it’s functioning.

I’ve downloaded a backup that the controller uploaded on our servers in March 2019, before the latest firmware update. I then checked in it the configuration for both the “Schakelaar Woonkamer WallC” (device #785) and “Schakelaar Slaapkamer WallC” (device #768 at that time).

Device #785 was configured while device #768 was not configured at that time either.
The situation was the same as it is at the moment: device #768 doesn’t report the “ManufacturerInfo” and thus the controller is not able to configure it.

It’s possible that the device goes into sleep mode before sending all the required information to the Vera and that might be what’s causing this issue. If this is the case I would recommend you that when you get the “Waiting for wake up…” message to do the Inclusion process on the device instead of the wake up.

It’s also possible that although the two devices are the same model, they might be running on different firmware versions. Device #785 is running on firmware version 1.1 while the firmware version for #768/#1140 is unknown.

If the above mentioned procedure doesn’t work, I would recommend you to get in touch with the manufacturer and see if there’s a way to upgrade/downgrade the firmware to version 1.1 on the device since we know that one should work.

Let me know how it goes.

Sender

Jun 26, 14:01 UTC

device #785

should be the same

Sender

Jun 26, 14:01 UTC

Sorry, I used the Vera generic zwave wizard

Sender

Jun 26, 13:57 UTC

Attached the device.

It worked till last firmware update… arghhh

Attachment(s)
20190626_155419.jpg
20190626_155434.jpg

Bogdan M. (Vera)

Jun 26, 13:23 UTC

Hello Sender,

Can you tell us what’s the exact model of this device (#1140)? It didn’t report any values for the “ManufacturerInfo” variable which makes it impossible for us to find more information on how exactly it should function and how we could configure it on the Vera.

Which wizard did you use to include it?
As far as we can see in the logs the device only reports 2 values on the Basic command class: “0” and “255”. This would indicate that it only has two buttons. However you mentioned that you used a 4 button wizard.

I look forward to your reply.

Sender

Jun 26, 09:36 UTC

Hello,

Is there someone there? I bit the bullit again regarding point 2 below.

Excluded the dives and included. It took me about 2 hours of pressing and releasing buttons etc. and I do not know what I did but is seems to be included again. No red lines, but it is not working anymore. I have added parameters and added the wizard with 4 buttons and 2 scenes, but it does not activate the scenes on button push.

The new device number is device #1140

Can you please support?

Hello Bogdan,

I may not swear but I will do for now to tell you my frustration. This is $%$# up!

I am putting so much time and effoert in this system, and every time there is something new problematic.

The below things you told, said, is this level of support the best within Vera?! NOTHINH PRESONAL TO YOU, but I would like to have real support now.

With regards to below problems:

  1. The values never update in the user interface. Cool you see it in the logs but that does not help me. The sensor is placed outside and the weather is pretty UV good. LUX and UV are always 0.
  2. This is MOST problematic now! I did in the past already, but did it again: - Manually set the “Configure” variable to “0” and then reload the engine on the controller. That does not chage anything. So I dit the second one:

set the “Automatically configure” option to “Default” → wake up the device → make sure that it is configured (the configured variable is set to “1”) → then set the “Automatically configure” option to “No” in order to avoid possible re-configurations of the device in the future. But that doe only introduce new problems. I do it NEXT TO VERA. But Now I am here:

Please wait! Getting the manufacturer

Please wait! Getting the name

ERROR: Unable to get any information on node

And the device IS NOT WORKING ANYMORE AT ALL. This is my little girls bedroomligth and tonight it most probably will not work anymore and it did before!

I NEED ALL THE HELP I CAN GET HERE!!!

  1. The is NO motion at all there? But nevertheless I have set parameter 1 to 100 and will observe. It always was 200 and worked well before previous firmware.

PLEASE help me

Bogdan M. (Vera)

Jun 21, 21:49 UTC

Hello Sender,

  1. I’ve checked the logs and I see that the values for the LUX and UV are updating as shown below.

LUX sensor update (device #1134):

  • as you can see, it did report values around 4500 for some time and then went to 0. The value of the “CurrentLevel” variable is actually the one displayed on the interface (you might have to refresh the browser if you know that the sensor should report the level but you don’t see it change)

06 06/21/19 12:25:44.698 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 4686 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:0 <0x77269520>
35 06/21/19 12:25:44.700 Device_Variable::m_szValue_set device: 1134 VV: 2 <0x77269520>
06 06/21/19 13:25:58.839 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 4686 now: 4572 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:0 <0x77269520>
35 06/21/19 13:25:58.840 Device_Variable::m_szValue_set device: 1134 VV: 2 <0x77269520>
06 06/21/19 13:25:59.441 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 4572 now: 4572 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 13:26:00.449 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 4572 now: 4572 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 13:26:08.190 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 4572 now: 0 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:0 <0x77269520>
35 06/21/19 13:26:08.191 Device_Variable::m_szValue_set device: 1134 VV: 2 <0x77269520>
06 06/21/19 14:25:35.801 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 4620 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:0 <0x77269520>
35 06/21/19 14:25:35.803 Device_Variable::m_szValue_set device: 1134 VV: 2 <0x77269520>
06 06/21/19 14:25:42.261 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 4620 now: 4620 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 14:25:42.371 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 4620 now: 4620 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 14:25:42.641 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 4620 now: 4620 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 14:25:44.391 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 4620 now: 4620 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 15:25:42.654 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 4620 now: 875 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:0 <0x77269520>
35 06/21/19 15:25:42.656 Device_Variable::m_szValue_set device: 1134 VV: 2 <0x77269520>
06 06/21/19 16:25:42.407 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 875 now: 0 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:0 <0x77269520>
35 06/21/19 16:25:42.409 Device_Variable::m_szValue_set device: 1134 VV: 2 <0x77269520>
06 06/21/19 17:25:37.141 Device_Variable::m_szValue_set device: 1134 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 0 #hooks: 1 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>

UV sensor update:

  • the value for the UV sensor (device #1136) does update but it always reports 0

06 06/21/19 10:25:42.483 Device_Variable::m_szValue_set device: 1136 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 11:26:00.220 Device_Variable::m_szValue_set device: 1136 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 11:26:00.224 Device_Variable::m_szValue_set device: 1136 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 11:26:00.261 Device_Variable::m_szValue_set device: 1136 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 12:25:44.998 Device_Variable::m_szValue_set device: 1136 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 14:25:54.583 Device_Variable::m_szValue_set device: 1136 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 15:25:42.794 Device_Variable::m_szValue_set device: 1136 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 16:25:42.567 Device_Variable::m_szValue_set device: 1136 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>
06 06/21/19 17:25:37.541 Device_Variable::m_szValue_set device: 1136 service: urn:micasaverde-com:serviceId:LightSensor1 variable: CurrentLevel was: 0 now: 0 #hooks: 0 upnp: 0 skip: 0 v:0x13419b0/NONE duplicate:1 <0x77269520>

We also tested this sensor model in our office and it did report the Lux and UV. However, for the UV we had to take it outside (in sunlight in order to report something different from “0”).

  1. For this device (#768) is see that the “Configured” variable is set on “-1”. This might be what’s causing the issue. It should be set on “0” when the “Automatically configure” option is set on “No”. I would suggest to either:
  • Manually set the “Configure” variable to “0” and then reload the engine on the controller
  • set the “Automatically configure” option to “Default” → wake up the device → make sure that it is configured (the configured variable is set to “1”) → then set the “Automatically configure” option to “No” in order to avoid possible re-configurations of the device in the future.
  1. Device #986 has only 2 child devices now: #1116 and #1117
    In regards to it always reporting the tripped state I would recommend you to try and set its sensitivity to a lower level (try setting it to 100 for example)

Have a nice day.

Sender

Jun 21, 08:24 UTC

UPDATE

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

So I bit the bullit and started all over for some devices (again !@#!@#).

This is now my situation and I still have the same issue for the multisensor:

Multisensor 6 in 1 which is now device number #1132

I would recommend you to try and set/adjust the configuration parameters related to the values that are not updating (mainly the thresholds that should trigger a report). I’ve linked below the Z-Wave alliance page with all the parameters available for this device:
https://products.z-wavealliance.org/products/2714/configs

It does not report LUX and UV as it should do. Parameter 101 says the send to send “all” value to group 1 (vera) but it does not work.

I had already added parameters to accomplish this. But it did nod lead to the desired state. This is the config (but most probably you can see this via support:

I also added the latest one but that did also not “fill” the UV value.

So problem still persists: NO LUX AND NO UV Values

The “Schakelaar Slaapkamer WallC” device #768 doesn’t seem to be one that is fully supported on our controllers and it seems that the controller is not able to fully configure it. This means that the Vera will keep trying to reconfigure the device. My suggestion from the last email to set this device on “Automatically Configure NO” still stands. As long as the device is functioning, setting that option to NO will not affect it but it will mean that the controller will no longer try to reconfigure it and the message will not be generated anymore.

This already was configured (do not configure automatically) and does not help to overcome this message (also not after waking up the device). I have 2 of these devices and the other works fine.

device #986 I have woken up. This thus happended: I may not swear. But again, by “reconfiguring” all my logic is gone. Ghost devices still there, but aother devices renamed and renumbered. And this sensor is constantly tripped as it should not (sensor is not battery powered, but mains powered.

Can you help out ONLY with these problems please?

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Hello,

See below.

Attachment(s)
image009.jpg

Sender

Jun 20, 08:17 UTC

  1. The “Schakelaar Slaapkamer WallC” device #768 doesn’t seem to be one that is fully supported on our controllers and it seems that the controller is not able to fully configure it. This means that the Vera will keep trying to reconfigure the device. My suggestion from the last email to set this device on “Automatically Configure NO” still stands. As long as the device is functioning, setting that option to NO will not affect it but it will mean that the controller will no longer try to reconfigure it and the message will not be generated anymore.

This already was configured (do not configure automatically) and does not help to overcome this message (also not after waking up the device). I have 2 of these devices and the other works fine.

Just change the battery: woke up device, message gone. Do not configure automatically and yet the message is back…

I may not swear. But again, by “reconfiguring” all my logic is gone. Ghost devices still there, but aother devices renamed and renumbered. Got the point?

#$#@@#@#$

For the below:

  1. When it comes to device #986, you should bring it closer to the controller and do the wake up procedure on it. At the same time on the Vera web interface click on the “>” button → go to Advanced → Commands and click on Configure Node Right Now. The child devices should disappear after that.
    Since all the logging options are disabled on the controller we cannot tell why they were created.

I have done what you said. Did not help.

The device is not battery powered. I can not see the “ghost” devices in ALTUI, only Vera interface.

Waking up does not delete them.

I have done it after enabling the logging in vera.

Hello,

See below.

Attachment(s)
image001.jpg
image002.jpg
image003.jpg

Sender

Jun 20, 07:50 UTC

Hello,

See below.

Attachment(s)
image005.jpg
image006.jpg
image009.jpg

Bogdan M. (Vera)

Jun 19, 21:55 UTC

Hello Sender,

  1. I would recommend you to try and set/adjust the configuration parameters related to the values that are not updating (mainly the thresholds that should trigger a report). I’ve linked below the Z-Wave alliance page with all the parameters available for this device:

https://products.z-wavealliance.org/products/2714/configs

  1. Is device #737 changing state from tripped to untripped and vice-versa continuously? Or you’re just referring to the fact that it stays tripped?
    As mentioned previously this state should be reported by the device and will remain in one state until the opposite state is reported by the device.

  2. The “Schakelaar Slaapkamer WallC” device #768 doesn’t seem to be one that is fully supported on our controllers and it seems that the controller is not able to fully configure it. This means that the Vera will keep trying to reconfigure the device. My suggestion from the last email to set this device on “Automatically Configure NO” still stands. As long as the device is functioning, setting that option to NO will not affect it but it will mean that the controller will no longer try to reconfigure it and the message will not be generated anymore.

  3. When it comes to device #986, you should bring it closer to the controller and do the wake up procedure on it. At the same time on the Vera web interface click on the “>” button → go to Advanced → Commands and click on Configure Node Right Now. The child devices should disappear after that.
    Since all the logging options are disabled on the controller we cannot tell why they were created.

For the issues related to the “Can’t detect device” message we need the logging options to be enabled at the time when the message is generated so that we can see what commands were sent from the controller and what the device reported (or didn’t report).
In order to be able to further troubleshoot these issues I would ask that you enable all the options in the “General” section on the Settings → Logs page.

I look forward to your reply.

Sender

Jun 19, 07:29 UTC

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Hello Bogdan,

Please see below, I have numbered the points for sake of clarity.

  1. Support is enabled again.

  2. Multisensor 6, device #1098 The device functions as far as I can see. But it does not report LUX and UV as it should do.

  3. For the tripped/untripped status to update. I never use those sensors, they are NOT connected physically. E.g. #737 is the master but the sensor is not connected but mostly detects motion?

  4. Fibaro smoke sensor (device #729), always worked well but not since a few days ”can’t detect device”. The batteries are brand OK. Wake up not working etc.

  5. device #768 WALL-C “Waiting for wakeup to configure device” it works well, Have woken up multiple times release the error but then it comes back again. It is a Wall-C button controller: https://www.robbshop.nl/amfilerating/file/download/file_id/393/

  6. I have random sensors staying tripped. I can untrip them via “luup.variable_set (“urn:micasaverde-com:serviceId:SecuritySensor1”, “Tripped”, 0, deviceid)” but this is not a solution. Currently I have 4 motion sensors tripped but not meant to be.

  7. I have extra ghost devices added again: device #986 is creating #1107 #1108 #1109 and this is one of the motion sensors not untripping.

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Bogdan M. (Vera)

Jun 18, 21:49 UTC

Hello Sender,

Apologies for the delayed reply.

For the tripped/untripped status to update on the Vera interface, the sensors have to report it. This variable is not updated by the Vera if the sensor doesn’t report back when its no longer tripped. I would ask that you do a test on one of these sensors and let me know the exact time/date when you did this along with the name of the sensor you tested. I’ll check the logs and see if the sensor actually reports the untrip status.

Note: the Verbose Logging and Lock Log Levels options should be enabled at the time of the test.

In regards to device #768, can you please let me know what is its exact model?
Did you try setting the “Automatically configure” option to “No”? This option if found if you click on the “>” button for that device and then on “Settings”.

In regards to the devices showing “Can’t detect device” it’s possible that they’re not responding to a poll on a specific command class. I’ll have to investigate the logs and get back to you on that one.

I’ve tried to access the controller but the code seems to have expired. Please re-enable the Remote Access and provide me the new code that is generated.

I look forward to your reply.

#27

Start reading here and 2 post up

And part 3 (45 pages…)

Sender

Jun 18, 20:36 UTC

Hello, when will I receive support and/or follow up?

Sender

Radu (Vera)

Jun 14, 10:37 UTC

Hello Sender,

We are sorry for the delay.

Please know that we have escalated your case to a higher tier for having your issues solved and if you may, please leave the Remote Access enabled as well so we may check your unit

Thank you.

Sender

Jun 10, 19:06 UTC

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

Hello,

Since the last firmware update I have ongoing an continuously arising motion, smoke, etc. battery sensor operated device problems. I have had SEVERAL Vera support cases but NONE OF THEM SOLUTED my problem. I see a lot of other peoples on the community having the exact same issue with their versa. What is wrong?

I have to ask… can you help. And with help I would like real help. Not a support case as the last few ones, leaving my Vera in a mess, introducing all other new sorts of problems and red lines in my interface, other device not functioning etc. Having me to exclude and include and start all over again. I am so sorry for the tone But I have so many bad experiences with Vera Support…

  1. I had an issue with a Fibaro FMGS-001 v3.2 and sold to another owner with no Vera and I bought a Multisensor 6. Update the sensor’s firmware via windows zstick and included in Vera. It worked for a few days but now it says “can’t detect device” (and I am not alone again – see forum!). I tried to set polling to 0. Etc. nothing helps to get rid of the red line. The device functions as far as I can see. But it does not report UV as it should do.

  2. Then I have this Fibaro smoke sensor (device #729), always worked well but not since a few days ”can’t detect device”. The batteries are brand OK. Wake up not working etc.

  3. Then I have this device “Waiting for wakeup to configure device” (device #768) it works well, Have woken up multiple times release the error but then it comes back again.

  4. I have random sensors staying tripped. I can untrip them via “luup.variable_set (“urn:micasaverde-com:serviceId:SecuritySensor1”, “Tripped”, 0, deviceid)” but this is not a solution. Currently I have 4 motion sensors tripped but not meant to be.

These are just a few examples, last week all 3 fibaro motion sensors didn’t work (see other support case). 181579 - escalated the case to a higher tier à black box, never heard back.

And for now as an extra example I see in Altui: 6/10/2019, 8:54:32 PM #50:Sensor Rook Hal Voorkant:Timed out waiting for the node to reply

Please if you are supporting me:

  • NO BACKUP REPLACEMENTS PLEASE
  • NO INTRODUCING OTHER PROBLEMS PLEASE
  • PLEASE DO NOT INTRODUCE OTHER PROBLEMS

*** PLEASE DO NOT CHANGE ANYTHING ON MY UNIT THAT MIGHT INTRODUCE NEW PROBLEMS ***

[Q5V9KQ-70DQ]

#28

FFS, trying to simply change a parameter… and FFS again stuck on Waiting for wakeup to configure device. WTF is wrong with this device support in Vera!?

EDIT: oh I forgot to mention, since the horror from above I had to exclude and include before working, but not once, not twice, not 3, not 4, 5, 6 no I think FFS more than 20 times!!! I am on:

image

And please Vera, do not to tell me to contact F support.

disclaimer: I am F frustrated now.

#29

At the risk of asking the obvious:
Have you woken it manually? What’s the set wakeup time? (Double check: this is battery operated?)

If these are the ones I think we’ve talked about before, I simply don’t have these issues. I do tend to carry them to Vera for wakeup

C

#30

Yes woke up, battery, etc… I have multiple. Some work well but if trying to change: hell…

#31

:frowning:

Now I need to add more characters

C

#32

Strange… I have several of those Fibaro 3in1 motion sensors, both old and new zwaveplus version. They all work fine.

#33

@Mai_Pensato thanks for letting me know.

#34

I think your situation is related to how many devices you have in your system. I recently added 10 devices to mine and I started to get all sort of crazy side effects, from data corruption to device not configuring, to losing their configuration, etc. I was almost stable before, I had 7-10 days of unusable system, with ZWave collisions and similar, but now it’s stable again - well, at least to be usable.

I will soon add a ZWay as secondary in order to configure a couple of devices without Vera’s intervention and then eventually migrate them to Openluup+Zway, while waiting for the new firmware.

#35

I’ve got 20 of the things in my system … maybe I can help …

  1. Sorry, a basic question: when you do the triple-click button press for manual wakeup, does the sensor light up blue?

  2. Did you by chance look in the luup log file at the time when you were trying to wake up the FGMS-001, to see if maybe it was trying to wakeup but some Zwave problem was going on?

  3. Are you trying to set a parameter to an invalid value, or maybe you’ve got the 1/2/4 byte decimal option set wrong on the parameter? Or maybe the collection of values you’re setting doesn’t work together? I haven’t seen this prevent a wakeup, but just checking (it usually comes back as “failed to set configuration”).

Could you please share what you’re trying to set the values to?

  1. I have on very rare occasions seen an FGMS-001 behave like that if I’m trying to change too many of the parameters at once. Are you changing one parameter, or many?

  2. If you just try to monitor parameters (select “monitor” in device parameters), without changing any, does that work?

  3. Have you tried changing the wake-up interval in the past on the devices that are failing? I had followed rafale77’s suggestion for longer wakeup times, and it laid my system to waste because two of my FGMS-001’s did not like the value I picked. They got into a mode where they just tried to wakeup about every 5 seconds and flooded the network. The only way I could recover was to pull the FGMS-001 battery and delete the device in Vera (couldn’t even unpair it), factory reset the FGMS-001, and re-pair. The FGMS-001 has the capability to “remember bad things” that only a factory reset can clear. Why did it affect only two of my devices? I bought my 20 sensors over about a 3 year spread, and those two were bought at the same time and I’m guessing had the same hardware and firmware configuration but different from the rest.

  4. You might try to do a Zwave backup. I have seen a few times on my Vera Plus (but never on VeraSecure) that something can get corrupted in the Vera’s device database that interferes with devices pairing and then operating properly, especially after a hectic sequence of unsuccessful paring attempts. When that happened, I would do a Zwave Backup, and when it was done, it would sit there on “Configuring Zwave Devices” for a long time, like 10-15 minutes, but when it was done, whatever was the device database problem got cleaned up.

#36

I added a lot of stuff last year, having bought a pack of gear from ebay. I had some issues like you describe. Ended up pretty much adding, backing up, adding, backing up.
Some of those were Fibaros so I just don’t see why the OP is having such issues. Unless it’s a newer / older version

C

#37
  1. Yes
  2. Yes, S2 errors
  3. no, I am perfeclty aware of what to set, 10 years vera experience. 1 parameter at a time. (Neo Coolcam works fine e.g.)
  4. https://manuals.fibaro.com/content/manuals/en/FGMS-001/FGMS-001-EN-T-v2.1.pdf parameters 6 and 2 to overcome the “keep getting tripped issue” that A LOT of other Vera users have. I want to have a trip on every motion on this sensor… (front door). and no it only trips if a person is there, sensitivity is low.
  5. never tried
  6. I did on some of these. But the one I am now talking about is fleshly excluded and included.
  7. I have a Vera Edge. I also have some “tricks” to push vera (rebooting, reloading, resetting trip values, etc. But believe me, I know what I am doing!

What is your highest device number in Vera? I am almost at 1600 :frowning:

#38

Highest device number = 1683. Currently, I have 159 Zwave nodes, and 358 total devices (many are virtual devices I manage with Lua code. I abandoned plugins and do everything in my own code).

I set parameter 6 to between 30 and 300 seconds across my sensors, but I have never taken parameter 2 off the default. I’ve never heard of the “keep getting tripped issue”, which probably means I have never experienced it.

If you’re getting S2 errors, I’ll offer up one more thing. Back in time when I was using the Evolve LCD-1 plugin, I found that I could not include an any security sensor no matter what I tried, because it would throw those S2 errors. The only way I could get the sensor to pair was to uninstall LCD-1 plugin, pair the sensor, then reinstall LCD-1 plugin. (Requests for help ignored by the plugin developer). I wonder if you might have a plugin that does something like that?

#39

No plugins…

Since you have such a high number, you have had also lot of issues with pairing unpairing, this must be. I have around 150 zwave devices as wel and almost no virtuals.