I have 2 PIRs from Kaipule … both have the same enclosure and a sticker IX-32 on them but or discovered as different things as they have different Type / ID.
@chris
I am up to clean up more in the DB.
Stumbled over this…
if there are 2 things with the same type:id… how does the binding decide for discover / initalization which is used?
First point - this shouldn’t happen - or shouldn’t be allowed at least… There are checks in the database to try and raise an error if this happens, but I suspect it’s not 100% guaranteed to catch all instances as it’s a little complex.
The binding will use the first set that matches the criterea.
Now - the extended answer…
There are 4 numbers used to match the thing - the manufacturer code, the device type and device ID, and the application firmware version. So, in the case you have above, these two devices are not the same and will not conflict as they have different firmware versions. One device is version 0 to 3, and the other device is version 23.23 to 255.255 (which is the maximum version possible).
This means that the binding thinks the device doesn’t support this command class on this endpoint…
There are a few possible reasons -:
The device really doesn’t support this command class on this endpoint!
There was an issue during the device interrogation and the device does support the command class, but the binding thinks it doesn’t.
There was no problem during the interrogation, but the device doesn’t report that it supports the command class, so the binding didn’t add this support.
Solution for 1 is obvious - remove the command class from the database. Since the device is sending this command class, this isn’t the reason!
Solution for 2 is to delete the XML or reinitialise the device to see if it now reports differently.
Solution for 3 is to add an option to the database for force the binding to add this command class.
1 and 2 are out
I added “add” to the command class config and will check if its gone
every other modifcation to the DB work as expected
Anyways the DB gives me some headache… a lot of channels are e.g. “generalarm” or “alarm_burglar” for tamper etc.
Now somebody changes this to a more fitting channel and by the next nightly I pull channels stop working.
I’m not sure if a local or manual definition of the thing would be more robust.
Why is 1 out? Is this device new for you or something you’ve used in the past?
I’m considering adding a lock to devices that are considered stable to avoid random changes. The idea would be that for locked devices, people need to request further access…
To be fair though, this is also what you are doing . You’re adding “random” configuration to a device to see what works ;).
This isn’t possible in any case - ESH needs the XML files inside the binding.
i know and I really thought about it because of that …and stopped remapping other devices to more clear and specific channels like ‚alarm_motionˋ to not destroy working stuff of other people.
I would love to rename these to be very specific and thats the reason I hoped a manual .thing or whatever could allow this some time … seems impossible after your last post.
it is sending the alarm. and the alarm i also processed by the corresponding channel.
so I already interpreted your post that it cant be 1 due to that.
for 2 I reinitialized … still the same.
that left me with no. 3
its a fibaro flood … was my first device ever
all channels in the DB do work as expected. only for ‚tilt‘ and ‚open enclosure‘ this error is in the debug…but works anyways
Yes - of course you’re right (I’m having a brane fade!).
I’m just surprised that this used to work without this addition to the database, but now doesn’t . The last time the database was updated for this device was March, so we can’t blame people for messing around with the database.
(not you - the manufacturer 
).
looks fine
. You’re adding “random” configuration to a device to see what works ;).
. The last time the database was updated for this device was March, so we can’t blame people for messing around with the database.