Ok, I thinkI am in the container. Thanks to the post of @murphys_law I google how to get “in”.
But the path is not there…
Is there a location that has the “history logfile” To maybe see why is sometimes is not responding anymore?
I have found below and change log line by means of test from 100to 1000:
But this seems to be “real-time”…
If you know the container name you can simply use:
docker logs <container>
That will show you the logs since the container started. I suggest you just pipe it into a file if you
are looking for something in particular.
You can follow the log live, tail it, by adding the -f switch, IE:
docker logs -f <container>
I dont think the logs he needs will be visible using that command, unfortunately.
The OpenZWave docker image he’s using is redirecting logs to stdout, you can see it in the Portainer logs snapshot he posted. The logs command would show him the same output.
I am sure I am missing something, but I can’t see it! 
Ahok. Just checked my own container, and did only see a few lines of the logs using “docker logs”, nothing from after the daemon was started.
Sorry for any confusion.
I’ll have to dig around to see where they moved the logs to then, because you’ll want the bits before everything starts blowing up.
AFAIK, you can only access the docker command in HAOS if you enable some debugging thing.
Yes please…
but till so far I also discovered… That when OZW addon is not running anymore it also seems my “other” MQTT sensors/devices don’t seem to work…
Can not find any logging for MQTT as well but I suspect the MQTT servers being blown up by OZW (I use MQTT only for 1 esp sending topics to it every 60secs).
No idea about MQTT addon, pure docker containers in use here 
sorry
The mqtt addon is a docker container (mosquitto)
Reporting back that for me it’s also working stable.
Does the new OZW support node_event?
HA 0.90.2 (OpenZwave Version 1.5.0) automation working:
- alias: "Living Room Light Switch Double Tap On"
trigger:
- platform: event
event_type: zwave.node_event
event_data:
entity_id: zwave.living_room_light
basic_level: 255
HA 0.117.6 using OZW doesn’t work:
- id: '1605643144564'
alias: Living Room Light Switch Double Tap On
description: ''
trigger:
- platform: event
event_type: zwave.node_event
event_data:
entity_id: switch.living_room_light
basic_level: 255
I have tried event type ozw.scene_activated and ozw.node_event, which didn’t work either. I have set
logger:
default: info
logs:
homeassistant.components.ozw: debug
and it look like OZW doesn’t receive the Basic set command. Was node_event support not added?
Is that a double tap event on a ge switch?
There is no Node Event in ozwdaemon (openzwave beta), and there may never be. There are only workarounds for now at least. https://github.com/OpenZWave/qt-openzwave/issues/60
Thank you @freshcoast, that works! Stop qt-openzwave, edit ozwcache_<id>.xml for node to set command class 32 look like this:
<!-- COMMAND_CLASS_BASIC -->
<CommandClass id="32">
<Compatibility>
<IgnoreMapping>true</IgnoreMapping>
<SetAsReport>true</SetAsReport>
</Compatibility>
</CommandClass>
start qt-openzwave, wait for things to settle, refresh the node in HA and I get 3 disabled sensors added. Enable and rename the the sensor and can now use that for automations:
- id: '1605643144564'
alias: Living Room Light Switch Double Tap On
description: ''
trigger:
- platform: state
entity_id: sensor.living_room_switch_basic
to: '255'
I’m going to assume your light switches are GE, but I think this will apply to some other doubletap events.
I guess I’m also assuming that was your trigger before. 
I recognice the 255 (and probably 0)
I’ve been doing this for a little longer than a month and it works fine. Of course the automation will change, but it willl still be a trigger on the event
EDIT: looks like we were both posting at the same time. haha. Glad you got it working
I would edit the actual device XML file, not the cache file. I’m surprised after refreshing the node that the setting persisted.
The basic sensor has some issues, notably when HA restarts. Your automation as written is going to trigger when you restart.
Agree about starting when HA restarts. I use the HA uptime sensor, but there are other ways to keep that from happening. Here is a simple automation I’ve been using. I use the doubletap on one switch to turn on a light without a switch nearby
- alias: Turn off TV Backlights in Bedroom from vanity switch
trigger:
- platform: state
entity_id: sensor.bedroom_vanity_light_basic
condition:
- condition: numeric_state
entity_id: sensor.ha_runtime_in_minutes
above: 2
action:
- service_template: >
{% if (states.sensor.bedroom_vanity_light_basic.state) == '255' %}
light.turn_on
{% elif (states.sensor.bedroom_vanity_light_basic.state) == '0' %}
light.turn_off
{% endif %}
entity_id: light.bedroom_tv_lights
Back in the spring I was pretty engaged in working through some of the refresh issues with the developer folks. This was all for a seasonal home and so for the summer I was off Zwave stuff but now I’m headed back to it. One thing that was bothersome at the time was that the ozw.scene_activated required a node id and those weren’t really available other than by manually looking at them. This seemed error prone and at the time there was some discussion about reintroducing a device notion and using that for things like scene_activated that needed the id. Doesn’t look like this occurred so is there any best practice developed yet that avoids hard coding node ids in automation triggers? At the time, templating, which seemed like it might work (use the entity_id and pull the node id attribute from there wouldn’t work in that context. So before I start from scratch here what is the best approach? Thanks.
Hi All,
I am not sure if the this is the post to use. I have setup the Openzwave and it is working fine. But my AEON Labs Zstick Gen 5 is showing me that it is not capable of using Zwave Plus. Why is this? How can i to solve this issue?
Versions:
OpenZWave Version 1.6.1392
qt-openzwave Version: 1.2.0
QT Version: 5.12.8