Somehow got into a state where there's a booking for a non-existent property. I suspect it got left when I was playing with listings and deleted one that had a booking. I haven't wanted to attempt to recreate the bug since there's no cleanup I can force/it'd make it worse.
app:12262025-12-21 08:34:37.790 PMerrorjava.lang.NullPointerException: Cannot get property 'locks' on null object on line 354 (method editBooking)
Attempted to fix this via:
- re-add "locks" to give me something to match to, but no benefit there.
- Adding and removing the built in app doesn't seem to clean things up.
Recommended way to clean this up? Is there a method I can get to the shell and remove related files themselves? (This is really what I need help with, all other comments in this thread below are about making lock control usability better and having a more stable platform)
Enhancement/Fix Request:
- When uninstalling app, need to clean all the bits up, or to force removal of a listing or booking.
- Property is more useful than "Listings" - Would be great to revert language (looks like things were property in error messages) references from Listings to Property.
More broadly a General Comment for stability and cleanup:
Really, this is an enhanced function to Lock Code Manager. The reason I was playing with this was the temporary code functionality - the gap is essentially the need to have a code work for a date range... temporary visitors to my house for instance. Observing the behaviors it feels like similar things are done in log messages (code reuse?) - and potentially conflict with eachother or the devices like having PIN Code length settings applied on locks.
So, thinking all the use cases for both apps I can come up with, it feels like these two could be better managed functionality wise as a single integrated app - something like "Property/Lock Group" to handle groups of locks and the rotation time for non-permanent lock codes. And "User/Booking" that uses a selection of "Property/Lock Group", with the ability to select 'Permanent' or 'Date Range' This'd then allow for a single UI approach and common code for the underlying logic, if you're already not calling the same routines.
The other use case I had to the two above was "Recurring Access" for specific day or hour ranges. Like saying a code works 9-5 M-F (an employee) or Every other Tuesday for a cleaning crew etc. This scenario is a bit more "nasty" for lock programming since it'd have to add or remove from the locks a LOT I'm not sure zwave locks and the underlying programming retry logic is solid enough to implement this frequency of changes, but it would round out the only other activities I could think of.
