After a recent move I’ve finally had a chance to get OpenHAB running again. I’ve done a clean install on a Raspberry PI 3b+ according to the instructions provided. I added my Z Wave controller and window switches without issue however, when I added the Monoprice Multi Sensor it was recognized in OH as a Zooz 4 in 1 sensor. As a result, I don’t believe the configuration changes I’m making to the device are being applied: the LED is blinking, temp is reported in Celsius (I know… Fahrenheit freak here…), and other items that indicate it is set to factory defaults.
Has anyone else observed this issue or have any idea how I can convince OH this is a different item?
Many ZWave devices are just rebadged devices from other manufacturers - probably it is correct. I’m not sure that I really follow your issue other than the name is not as you expected?
My ultimate issue is that I cannot change the configuration items (temperature scale, sensitivity, etc). The reason I point at the incorrect device is because this was working previously (configuration items could be changed and device was reported as Monoprice) but now, with the new install, it is only working at a basic functionality.
So you mean that this exact same device was previously reported as a Monoprice? It’s reasonably unlikely the manufacturer changed - most Monoprice devices are made by Vision who also make a lot of the Zooz devices, so maybe the name was updated in the database.
When you say you can’t update the parameters, what are you doing, and what is happening? Please provide some information that can help understand what is happening (or even better - debug logs ).
Apologies for being vague. I’m at work so I can’t provide logs just yet (just trying to pick the brain of the masses while I’m away from home) but I can describe what I was trying. This same device could previously be configured through Habmin by selecting the thing, scrolling to configuration, picking a new value from the dropdown (temperature scale, for example, has Celsius and Fahrenheit), and clicking save at the top-middle. When I was attempting this last night, a green pop-up would appear in the upper right saying the thing was successfully saved, but nothing would change in the behavior of the device.
I tried to both heal and reinitialize the device using Habmin and, after leaving it overnight (network query/healing is set for 2am) it was still reporting in C and using the status LED after I had told it to use Fahrenheit and turn off the LED.
Are you waking up the device after changing the configuration? This device is a sleeping device, so the data will not be transferred to the device immediately - it will only transfer after the device wakes up (maybe one hour, or one day later?).
No, I am not waking the device after changing the configurations. I was not aware there is an operation for that; could you please describe how to do it?
As I’ve poked around more I’ve noticed that luminance doesn’t appear to be reporting (this is okay as I don’t use it) nor does the battery level (much more important). I’ve tried configuring the battery level as a number and a string and nothing seems to work. Could this be related?
Please read the documentation for the device - it is device dependant and different devices have different button presses.
Is this the debug log (ie you enabled debug logging, and you are looking in the openhab.log file) or is this the events log? With debug enabled, there should be something received if the device is actually doing something.
Probably you need to configure the device to send this data, so yes, you need to get configuration working.
Under normal operation, the sensor is in "sleep" mode... When it detects motion or detects a configurable change in temperature, humidity, or light levels, the sensor will automatically "wake up" and broadcast an alarm signal to the network.
So, between moving around the room, changing temperature levels, and changing humidity levels from the recent rain, yes I have been waking the device.
No, but here is the log at a debug level:
==> /var/log/openhab2/openhab.log <==
2018-07-13 06:47:32.523 [ERROR] [e.internal.WriterInterceptorExecutor] - MessageBodyWriter not found for media type=text/plain, type=class java.util.Collections$UnmodifiableCollection, genericType=classjava.util.Collections$UnmodifiableCollection.
2018-07-13 06:47:52.866 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update received
2018-07-13 06:47:52.873 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update config_1_1 to 0
2018-07-13 06:47:52.875 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 2: Creating new message for application command CONFIGURATIONCMD_SET
2018-07-13 06:47:52.899 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 2: Putting message SendData in wakeup queue.
2018-07-13 06:47:52.906 [DEBUG] [class.ZWaveConfigurationCommandClass] - NODE 2: Creating new message for application command CONFIGURATIONCMD_GET
2018-07-13 06:47:52.909 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 2: Putting message SendData in wakeup queue.
==> /var/log/openhab2/events.log <==
2018-07-13 06:47:52.940 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:ea80ab6f:node2' has been updated.
2018-07-13 06:47:52.948 [vent.ConfigStatusInfoEvent] - ConfigStatus info [configStatusMessages=[ConfigStatusMessage [parameterName=config_1_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]
It appears there is something happening on the Z Wave bus (perhaps the heal operation at 2am?) that is allowing config messages to go through. I wasn’t bugged by the flashing temperature range LED last night and it was no longer flashing red when detecting motion. Additionally, this morning I noticed the battery level is reporting. I don’t recall having to wait for hours and hours to get configuration items to change like this but they appear to be working albeit slowly.
I’m not sure that this is really a “wake up”. Most devices will not really “wake up” - most devices will send the alarm signal so that the controller receives the notification, but this does not mean that the binding can send to the device. For this to happen, the device needs to send a specific WAKE_UP_NOTIFICATION - are you sure that the device is really sending this? Normally, it’s not the case, but maybe this device works differently.
As above, please double check that the WAKE_UP_NOTIFICATION is received.
Here we see the data is put into the queue waiting for the device to wake up - I don’t see any wakeup messages, so the binding will not be able to communicate with the device until this is received.
It won’t be the heal - but I guess the wakeup interval is set, and it wakes up every hour/day/?? so it will ultimately work even if you are not manually waking the device.
I’m assuming the device you have is the ZSE40? If so. the device manual states -:
WAKE-UP MODE
Use the Wake Up command to set wake-up interval for the sensor (from 10 minutes to 1 week) to report
back to the controller. You can also press and release the Z-Wave button once to wake up the device
manually.
I believe that it will not wake up and so that it receives data from the binding when it sends notifications. You either need to press the button, or wait until the timer expires - this is the normal way ZWave devices work, and is also my reading of this device manual (assuming I found the correct device as I don’t think you said what it is?).
The device I’m using is the “Monoprice Z-Wave Plus PIR Multi Sensor, Temperature - Humidity - Light” PN 15902. The manual is nearly useless regarding the wake up as it simply says:
Looking at the Wakeup Configuration for this thing in Habmin, I see that it’s set to wake every hour. It’s been an hour since I last changed the settings and this is what I’ve captured in the log (truncated because of buffer size on my terminal app, note that the multisensor is NODE 2):
No, there’s no trouble - it’s just queuing the message as expected. The device needs to send the WAKE_UP_NOTIFICATION. When the binding receives this notification, which means it is able to receive commands, then the binding will send the commands. If the binding were to just send them when the device is asleep (which is approximately 59 minutes and 50 seconds of each hour) then it will fail. The binding therefore queues the messages until the device reports it is awake.
When providing logs, please just provide the openhad debug log, and preferably use the </> button to format (I’ve reformatted your message above ). This makes it a lot more readable, and also able to be processed using other tools.
I’ve been wondering what the correct braces are to use for logging quotes, thanks for clearing that up.
I was able to get the wakeup period shortened from 60 minutes to 5 and used that to attempt to get the configurations passed that have been giving me problems (specifically reporting the temperature in Fahrenheit). After several attempts of changing things through Habmin (and waiting for the next wake up event) I remembered there are some things that can be changed in the paper UI. Navigating to Configuration > Things > Multisensor there is an edit icon next to the temperature channel. Although Habmin states this channel to be reporting in F (after several wake up events) this edit field still showed Celsius. I changed it to Fahrenheit, waited for the next wake up period, and voila! the temperature is not being reported in the new units… Would it take some serious log diving to explain this difference or is the paper UI the preferred place to make this change?
).