Read the instructions for the portainer add-on. The containers are tagged so as to be hidden and you have to go in and remove the tag to get access to them.
There is SO much to readā¦ where to start? Itās like all ā¦ if you know where to find it it is easyā¦
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