Sorry, that was unclear. I switched both on in HA, as you can see from the later screenshot.
Those changes remain, but sensor readings remain the same as they were when first added.
Yes, but there is no USB port on the outside or under the snap-off cover. Maybe there is if I remove the inner cover, but I don’t need to update.
It reports every 60 seconds on ST. It shows as USB powered (read-only) in HA:
Does it show as something different elsewhere?
Sorry for my slowness here.
So do you want the JSON file resulting from the Download diagnostics button? It looks like a config file, not a log file.
Or do you want the home-assistant.log file?
Is it worth putting in batteries and turning on Parameter 12 above?
Are you referring to this one?
These are not the same settings as you had in ST.
ST:
This screenshot:
I mean, I guess I’d still expect power entities to update, but you don’t have any energy reporting enabled (kWh) so those won’t change.
Are you trying to measure, power, energy, both?
Yes, but there is no USB port on the outside or under the snap-off cover. Maybe there is if I remove the inner cover, but I don’t need to update.
I guess Aeotec would have to answer to that, I was just going by the manual. The device does not report OTA firmware update support, so it can’t be done through ZJS.
It reports every 60 seconds on ST. It shows as USB powered (read-only) in HA:
Apparently the device realizes it’s on “USB” power, but I’m not sure Z-Wave JS agrees because it reports:
"isListening": false,
Still, somehow you were able to change the settings anyways, so I’m not sure if this matters then.
I’m asking for the driver log file. Difference in tilt sensor performance between ST and HA - #2 by freshcoast
Yes. I was trying to cast a wide net, as Groups 1 and 2 appear to correspond to the legs in the panel.
I’m fine with power only. Turning on all of those for Group 1 didn’t change anything that I could see.
Still, it’s progressed from requiring a button press for listening to taking changes without one.
I’m trying to comply. From that page:
Set the log level for
zwave_js_servertodebug. This can either be done in yourconfiguration.yamlin theloggersection, or using thelogger.set_levelaction. When the integration detects that the log level has been set todebug, it will also set the Z-Wave JS logs todebugif the level isn’t alreadyverbose,debug, orsillyand will include those logs in the Home Assistant logs. The Z-Wave JS logs can be found under the logger namezwave_js_server.server.
Apologies, but I don’t understand that last sentence. I see 435 entries with “zwave_js_server” in home-assistant.log, which drove my question. Is “logger name” a heading in that file, or does it refer to a separate log file, possibly in a different directory?
Or should I turn on the logging window, then exclude and include again?
Those are the logs from HA (#1). Logger name is the component name that is logged.
Except you posted an actual driver log from a different file in Difference in tilt sensor performance between ST and HA - #3 by Jz777, unfortunately I can’t tell you how you did it, only provide the methods to get them. I suspect you are using ZUI and opened the driver log file (option 2), but I don’t recall you providing which addon you are using. So maybe look there if so, easier than HA logs.
No, not UI.
I could do it again to get more specific ones from the window at /config/zwave_js/logs, but in the meantime I’ll just post the whole home-assistant.log in parts. Let me know which is easier for you.
Ok, then did you enable log_to_file in the addon? In that case, the log is at /addon_configs/core_zwave_js. The raw driver logs are much easier to read than the HA logs, but the HA logs also include the messages sent to the websocket server, which is sometimes useful.
part 1
part 2
part 3
part 4
This might be helpful, from the window in the last few minutes. As I knew I’d be logging, I didn’t change the interval to 60 sec.
Ok, well it will take a little time to look at those. FYI, it looks like you’re actually using the logging window right? It will stop listening unless you have HA configured not to close the UI websocket connection. The file options avoid this problem and so you don’t have to keep the window open.
I guess I didn’t, because the only thing in that directory is a cache directory, with no names that look like logs.
Again, if it is easier for you, I can start over.
I only figured that out in the last hour. 
Good to know, thanks.
I wrote my thesis in 1986 in vi on a VAX running UNIX, then my UNIX since then has been limited to MacOSX troubleshooting as the entire IT department for a 35-person research institute, so finding a lot of this takes time.
My deepest recent achievement was a triple-booting Mac/Win/linux Hackintosh. At least my son was impressed.
Really, I’m just fine repeating this tomorrow, as I’ve already learned a lot today that I think would greatly reduce your time spent. Thanks!
No worries. I’d suggest enabling that log to file option just to make the collection a little easier, and you can grab it at anytime.
Thanks. Just for reference, it took me multiple searches to figure out how to turn on log_to_file in (edited as per posts below):
…/hassio/addon/core_zwave_js/config
For the good news…
I looked at the log at /config/zwave_js/logs last night, the one you advised me not to do, and saw events like this for kWh and power (power shown):
2024-11-23T15:42:56.880Z SERIAL « 0x010e0004001508310504640006c93a49 (16 bytes)
2024-11-23T15:42:56.883Z SERIAL » [ACK] (0x06)
2024-11-23T15:42:56.886Z CNTRLR [Node 021] [Multilevel Sensor] Power: metadata updated [Endpoint 0]
2024-11-23T15:42:56.888Z CNTRLR [Node 021] [~] [Multilevel Sensor] Power: 443.96 => 444.73 [Endpoint 0]
2024-11-23T15:42:56.890Z DRIVER « [Node 021] [REQ] [ApplicationCommand]
└─[MultilevelSensorCCReport]
sensor type: Power
scale: Watt
value: 444.73
The default entities were still not updating from the original inclusion. I looked for an entity called “MultilevelSensorCCReport” to put on my dashboard, but could not find one. There were kWh and other power updates too in the log that I didn’t need, so I went into the config.
I left Parameter 111 (Report Interval (Group 1)) at 60 sec.
I turned off all switches except Parameter 101, Bitmask 2 (Automatic Report: Group 1 - MultiSensor Wattage (Whole HEM)), since the log mentioned “MultiSensor.”
The kWh log entries stopped and the power continued. I think–but do not clearly remember if I checked–that the default entities shown remained unchanged last night.
This morning, I had the idea that something might have been added to the Overview dashboard, since something was reporting. Nothing had been added, but now the default entities were updating every minute!
So the one thing I wanted is working as desired. I suspect the same would be true for usage in kWh. I don’t know whether the Parameter 101, Bitmask 2 switch being on has anything to do with it, but at this point I’m afraid to experiment and lose it. I’m not sure whether Parameter 1 should be 120 or 240 v; nor whether I should be using Power, Power (1), or Power (2), but I can use a known load to figure that out.
TL;DR–turn on the switches for desired MultiSensor parameters and wait.
Just posting this for someone else; not sure if this post should be checked as the solution. Thanks for all your help.
I’m sorry but this is literally the link I posted several times and even took a screenshot of.
You also said you were not using Z-Wave JS UI.
“log_to_file” is a Z-Wave JS core add-on option, not ZUI option.
So which add-on are you using? Both of them? Because you can’t do that.
Sorry, you are correct.
I am not using UI. The page I had trouble finding was
…/hassio/addon/core_zwave_js/config
That trouble was almost certainly my own fault. Again, thanks for the help.
