As I mentioned way up, it will be in "Current Logs" if that page was opened at the time when the log entry was generated (my suggestion was to wait and try it after that). But yes, you can also see it under "Past Logs" (at least until it gets purged).
I second the advice from @neonturbo above on the Z-Wave issue. Z-Wave can certainly be quirky at times...
All, I stated in an earlier post that I was going to stop looking that the zwave details and was told not to do that. they said I should make sure that the mesh was good. Also, if a button doesn't work don't put it on the details.!!!!! This is the stupidest thing I have ever seen in tech. I have taken many breaks. Trust me. Why these things (ghosts) show up and can't be deleted is beyond me. All the includes I did this morning worked perfectly and the devices are working. I will go away and shut up.
I think there's a balance (though you will get some different opinions from different people and some more aggressive about this than me): ghosts can cause problems but aren't a guarantee of problems, and since you don't seem to have any other option at the moment, leaving it alone and coming back either never or if/when you have a problem is as good as anything. 
Again, your problem with the button is unusual, and if my guess is correct, is likely related to a since-fixed bug in the Z-Wave SDK that older databases might be stuck with. Of course, any button that is there should work as intended; this is unusual, and the attempts above to try to find a log entry were the best way to help figure out why.
Just remember that the root of the issues are not due to Hubitat. They're due to Silicon Labs, the makers of Z-Wave. Might the Z-Wave JS people work around issues faster than Hubitat? Sure. But that's not assured and it addresses symptoms, not causes.
IMO anyone new to home automation should try to steer away from Z-Wave. I understand it's not always possible. It's also not always the Z-Wave chipset itself, device makers bear responsibility too.
SiLabs controls the spec to a much tighter degree than Zigbee so every manufacturer is at the mercy of the quirks of the underlying system. Unlike Zigbee, the Z-Wave devices are stored in a DB on the radio chipset itself which adds to the "fun" when trying to migrate from one hub to the next.
Theoretically the lower frequency should allow for better travel through walls and longer distances - in practice thanks to the mystifying routing rules and the wonders of radio wave propagation at a given location it's not always as clear.
To be fair the system has been improving with more recent firmware updates (SiLabs not HE).
Danish company Zensys was responsible for Z-Wave's design around 1999; it was proprietary and low level specs weren't publicly documented. To allow product development, home control system OEMs obtained access to technical details (the SDK, under NDA) for a fee; Z-Wave chipsets through the -500 series were sourced by Sigma Designs (Mitsumi signed up to produce a '-400 series' chipset but that but apparently never panned out; it didn't obtain rights to the -500 or later versions). Sigma Designs acquired rights to Z-Wave from Zensys and was itself later acquired by Silicon Labs in 2018.
In 2005, the Z-Wave Alliance was formed by the OEM's; all chipsets remained single source (the Alliance was focused on marketing) with no further disclosure of technical details. The PHY, MAC, SAR & LLC layer spec was documented and released around 2015 as an ITU specification (not to be confused with an open peer reviewed IEEE standard); this allowed interoperability to be verified. Still, no details of the routing layer were documented. Hence, assumptions about behavior at the network layer were derived from reverse engineering.
A 2012 EE Times article had this to say about Z-Wave development:
"The SDK contains all needed documentation and code to build a firmware that covers all three parts of the communication stack. The NET, PHY and MAC layer are well-defined and shall not be altered by the developers. They are therefore not available as source code but as precompiled libraries only. The libraries are complemented by plenty of sample codes to show the usage of the libraries and to document the implementation of a Z-Wave compatible code.
The closed source of the libraries has its pros and cons:
• Con:
In case there are bugs in this library, the turnaround cycle is much longer and for developers debugging is harder.
• Pro:
Nobody can change the lower part of the protocols. This makes sure that at least for this part all Z-Wave products interoperate without problems, since they all rely on the same well-managed code base."
In an effort to compete with the Zigbee Alliance, SiLabs announced that it would release Z-Wave's specs as an open standard in 2019, opening the door to third party designs certified by the Alliance (there have been no takers to date). A couple of years later the network layer spec surfaced (along with Z-Wave LR), providing an authoritative description of Z-Wave routing.
To date Z-Wave products remain single sourced by SiLabs which relies on external chip fabs to produce them.
My speculation: having been associated with projects transitioning from product development to product engineering in a former job (design -> bug fixing and maintenance) I've seen this play out before. It's especially difficult when intellectual property is transferred, potentially without the simultaneous transfer of human captial. Touch one thing and another one breaks... likely the multi-year delay in the release of the specification had a lot to do with SiLab's itself needing to reverse engineer and document nuances of the protocol that departed with the original designers decades ago (along with mitigating issues that popped up as the protocol evolved).
Just to be clear the button does work and if you open up current logs in another tab BEFORE you hit the button you will see that.
To reduce nonsensical logs I recommend you turn off all logging on all devices and apps unless you are debugging it. It makes it much easier to "see the wood through the trees" as it were.
Again the button is working but it's likely that another device with the same information has paired correctly later down the table. There is a reason why you can only join one z-wave device at a time (unlike ZigBee) you must confirm it joined correctly and working before you move on. To do this you test the device and check the z-wave page, if you end up with two new ones one with full details and one without you need to stop. You down power (battery or mains) the new working one and refresh and hit the remove on the "ghost" follow the logs and it WILL remove it. Some times it takes a few presses but it does work.
Once you have just the correct new device you power back up and test again to confirm. Turn off it's logs and move on to the next. All this is so important to do but only with z-wave you just don't get the issues on ZigBee.
Following this advice though will work I have done it many times and sorted and fixed many other hubs it's just logical planning methodical thinking.
Download the Hubitat app
