I know that Battery devices have to be able to communicate to the main controller - they can’t communicate with another device to get a message to the main controller…
However would a range extender allow me to use a battery PIR sensor that can’t currently reach the controller?
I thought that battery devices can’t act as relays, but can communicate to the controller through mains-powered nodes.
I think you might be able to get reports however if you try update parameters in Habmin the device wakes up and goes to sleep before the controller can send anything unless the device is connected directly to the controller…
So I’m wondering if an extender counts as being directly connected or if it just acts like another repeating node.
It would seem like a serious flaw in the Z-Wave protocol to require a direct path between the controller and a battery node in order to configure the battery node, but I’ve never seen the situation first hand. I look forward to an answer. 
This is one example of @chris saying what I’m talking about:
https://groups.google.com/d/msg/openhab/zCaCbRwaXEU/6u6CoZk5-dYJ
Although I seem to remember more explicit ones than that I cna’t find them.
No - this is incorrect - battery devices can send data to the controller via other (mains powered) devices.
No - this is incorrect. The device should not go to sleep until told to do so by the controller. When a device wakes up, it sends out the wakeup to the controller - the controller doesn’t need to be directly connected (but see below for more on this). The device should stay awake for a ‘reasonable time’, or until the controller tells it to go to sleep.
The issue is that in order to wake a device up, it needs to initially be in range of the controller. This is because the NIF (Node Information Frame) is not routed as it is a broadcast frame. Once the wakeup class is configured, then WAKE_UP messages are sent - and these are not broadcast (*) so are routed within the network.
(*) It’s also possible to set the wakeup node to 255 which tells the system to send a broadcast. This can be used to send the wake up to multiple controllers. However, since this is broadcast, the wakeup is not routed, so the device needs to be in direct contact with the controller…
Chris
I should add that a range extender is pretty much exactly the same as a mains powered device, so if you already have mains devices in your system that are ‘en-route’ then they should be doing the same job as a range extender…
Then I really need to find out why my PIR sensor can’t talk to the netowk when placed 3 or 4 meters from a wall socket that can recieve ZWave commands…
I didn’t try this last night but I’m wondering if having either a masterController or enableSUC will help me? I’ve got a ZWave Plus USB stick connected to the computer. I could also buy a fob for adding devices if this would help the outside sensor communicate with the rest of the network?
At the moment it would have to be connected like this:
Controller ------------- Power Socket Node --------------------------- PIR Node. However when I did include it it was right next to the controller… maybe that caused the problem?
Neil
I don’t think adding a Fob will help at all. The primary controller should already get the updates I think. However the SUC are really only of use (in my opinion) when you have nodes moving around (ie for fobs, remotes etc) since the SUC is really there to keep track of network changes (at least that’s my understanding)…
Ok - is there a way to include a PIR when it is in range of the controller and then fix it’s routing when it becomes out of range and needs to communicate via another zwave device?
Do I need to do anything special as it doesn’t seem to “Just work” after putting the PIR in it’s final location.
It should sort itself out assuming that there are devices available that can provide a route back to the controller. If there’s no route then it won’t work…
At least that’s always been my experience.
Hi Chris,
it seems, that I have a similar problem. I use a raspberry PI2 with Jessie and Openhab 1.8 with zwave binding 1.8.0 with a Aeotec Gen5 USB Stick. The last weeks I tested 4 Fibaro Door/Window sensors (FGK101) and all worked fines and reliable as soon as they are in the range of the main controler (USB Stick). The problem is, that the range of the USB stick in not enough, so I installed Aeotec Extender and a fibaro wall plug FgWPE at the edge of the USB Gen5 Stick all works fine. HABmin shows a meshed network and using these both power zwave devices I could extend the range (the wall plug is behind the usb stick (usb stick ---- extender ------ wallplug.
My problem now is, if if move one of my fibaro FGK101 out of the range of the controller (usb-stick - extender - wallplug - FGK101) I loose the door/window sensor. Doing a network heal shows that the sensor is connected as before with the controller node 1 and another door sensor (as before within the range). After a reload of Openhab sometimes HABmin shows that the sensor is connected with the powered devices but move the magnet to and from the sensor has no effect. It seems, that the controller usb stick doesn’t could connect via the powered device to the sensor.
After another reboot the apart door/window sensor is grey and a healing/initialising the node, netwrok heals have no effect.
I don’t really understand your discussion with broadcast and routed messages. Are there any switches I can set to influence the sensor behavior or are there any other things to do … the problem is, that if I don’t bring it to run zwave is no option because I need a broader zwave extend to reach all in windows and doors in this building. Does it makes sense to update the zwave bindung to 1.8.1 any other ideas to solve this problem.
Many thx in advance
Peter
I don’t think there’s anything you can do on the sensor to improve things as such, however, you should make sure things are configured properly. Make sure that association group 3 is set to node 1, and make sure that the wakeup command class is also set to target node 1. I think this is about all you can do…
To set these, you should try and make sure that the device is in direct range of the controller - not going through a router since the wakeup messages won’t be sent through the router (this is a broadcast message). I would try and configure it up close to the controller, and then move it away and see how it works…
If you’ve already done this, then I’m not sure there’s too much more you can do…