I try to switch over from onewire1 to onewire2.
If I define my things with a name and a location, I get an error message:
Thing basic iButton_Ulrich "Schlüssel Ulrich" @ "Flur EG"
[
id="01.05D98A1A0000",
refresh=2
]
{
Channels:
Type present : Present
}
03-Okt-2019 13:23:03.852 [DEBUG] [internal.owserver.OwserverConnection] - read pid 1667 -> connection still alive
03-Okt-2019 13:23:03.919 [DEBUG] [internal.owserver.OwserverConnection] - failed requesting messageType READ, size 46, controlFlags 0x00000104, payload '/01.05D98A1A0000/type'->return code -1, size 24, controlFlags 0x00000104, payload '' [I/O error: exception while reading packet - Read timed out]
03-Okt-2019 13:23:03.951 [DEBUG] [ternal.handler.OwserverBridgeHandler] - updating thing properties for onewire:basic:Flur:iButton_Ulrich failed: I/O error: exception while reading packet - Read timed out, adding to end of list
03-Okt-2019 13:23:04.984 [ERROR] [ternal.handler.OwserverBridgeHandler] - refresh encountered exception of class java.lang.IndexOutOfBoundsException: Index: 0, Size: 0, please report bug
md5-6db3afd7e2badce6077d9111f1fd640c
Thing basic iButton_Ulrich
[
id="01.05D98A1A0000",
refresh=2
]
{
Channels:
Type present : Present
}
md5-d5234ccbc0045020b6a4b68eac802f63
03-Okt-2019 13:35:08.650 [DEBUG] [internal.owserver.OwserverConnection] - read pid 1667 -> connection still alive
03-Okt-2019 13:35:08.718 [DEBUG] [internal.owserver.OwserverConnection] - failed requesting messageType READ, size 46, controlFlags 0x00000104, payload '/01.05D98A1A0000/type'->return code -1, size 24, controlFlags 0x00000104, payload '' [I/O error: exception while reading packet - Read timed out]
03-Okt-2019 13:35:08.761 [DEBUG] [ternal.handler.OwserverBridgeHandler] - updating thing properties for onewire:basic:Flur:iButton_Ulrich failed: I/O error: exception while reading packet - Read timed out, adding to end of list
In both cases, the iButton isn't connected.
If I disconnect the iButton I get this this message in the event log
2019-10-03 13:43:57.102 [hingStatusInfoChangedEvent] - 'onewire:basic:Flur:iButton_Ulrich' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): slave missing
and when I connect it it is this message:
2019-10-03 13:47:29.587 [hingStatusInfoChangedEvent] - 'onewire:basic:Flur:iButton_Ulrich' changed from OFFLINE (COMMUNICATION_ERROR): slave missing to ONLINE
I onewire1 I had a property ignoreReadErrors, which doesn't seem to be available anymore, but could solve the messages above.
Nevertheless I expected a status change at the item belonging to the thing channel. But this isn't happening.
Switch swi_iButton_Ulrich "Ulrichs Schlüssel [%s]" <keyring> (gLog) { channel="onewire:basic:Flur:iButton_Ulrich:Present" }
I'm using openhab 2.5.0 M3 on Raspbian GNU/Linux 9 (stretch).
Please set the binding to TRACE. I would like to see where the Exception occurs.
Second: That is the expected behaviour. Why would you want to ignore read errors? If it can't be read, the sensor/iButton is not available. So "OFFLINE" is the correct state. In my setup the state of the present channel is also properly updated.
I tried to reproduce the Exception, but I couldn't anymore.
In the meanwhile I had updated to 2.5.0 M4.
For the iButtons it is an expected behavior that they are not connected. Therefor it is not en error if they aren't connected. Nevertheless OFFLINE is correct.
The state still is not available in my items. It is always NULL. The thing itself is ONLINE.
Here are my current definitions and the TRACE-log:
Bridge onewire:owserver:Flur "OneWire Bridge" @ "Flur EG"
[
network-address="127.0.0.1"
]
{
Thing basic iButton_Ulrich "Schlüssel Ulrich" @ "Flur EG"
[
id="01.05D98A1A0000",
refresh=2
]
{
Channels:
Type present : Present
}
Switch swi_iButton_Ulrich "Ulrichs Schlüssel [%s]" <keyring> (gLog) { channel="onewire:basic:Flur:iButton_Ulrich:Present" }
01-Nov-2019 12:23:38.999 [TRACE] [ternal.handler.OwserverBridgeHandler] - refreshTask starts at 1572607418998, 5 childs
01-Nov-2019 12:23:39.088 [TRACE] [ternal.handler.OwserverBridgeHandler] - refresh: getting handler for onewire:basic:Flur:iButton_Ulrich (5 to go)
01-Nov-2019 12:23:39.121 [TRACE] [ternal.handler.OwserverBridgeHandler] - onewire:basic:Flur:iButton_Ulrich initialized, refreshing
01-Nov-2019 12:23:39.155 [TRACE] [.internal.handler.OwBaseThingHandler] - refreshing onewire:basic:Flur:iButton_Ulrich
01-Nov-2019 12:23:39.188 [TRACE] [internal.owserver.OwserverConnection] - owServerConnection already open, skipping input buffer
01-Nov-2019 12:23:39.223 [TRACE] [internal.owserver.OwserverConnection] - wrote: messageType PRESENT, size 41, controlFlags 0x00000124, payload '/01.05D98A1A0000'
01-Nov-2019 12:23:39.959 [TRACE] [internal.owserver.OwserverConnection] - read: return code 0, size 32, controlFlags 0x00000124, payload '??ي???�'
01-Nov-2019 12:23:40.022 [TRACE] [internal.owserver.OwserverConnection] - presence /01.05D98A1A0000 : ON
01-Nov-2019 12:23:40.056 [TRACE] [.internal.handler.OwBaseThingHandler] - refreshing sensor 0 (/01.05D98A1A0000)
same here (openhab 2.5.1).
I have configured one DS2401.
the events are there
2020-02-02 17:27:47.102 [hingStatusInfoChangedEvent] - 'onewire:basic:onewirebridge:BueroMichaFensterRechts' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): slave missing
2020-02-02 17:28:00.138 [hingStatusInfoChangedEvent] - 'onewire:basic:onewirebridge:BueroMichaFensterRechts' changed from OFFLINE (COMMUNICATION_ERROR): slave missing to ONLINE
but the Item shows nothing.
things-file
Thing basic BueroMichaFensterRechts [id="01.FCD42D170000", refresh=2] {Channels: Type present : Present}
items-file
Switch BueroMichaFensterRechts "Büro Micha Fenster Rechts [%s]" <window> {channel="onewire:basic:onewirebridge:BueroMichaFensterRechts:present"}
sitemap-file
Text item=BueroMichaFensterRechts
This was working with openhab 2.4. The temp-sensors are still working as expected after changing to the new basic-typ.
It was a bit difficult to find since I didn’t experience it in my setup. It only happens after thing creation, so managed thing won‘t suffer from this bug after a restart. Unmanaged things (i.e. things configured in files) are always created from scratch, so they are affected any time.
the fix is working in my installation. many thanks!
Most helpful comment
It was a bit difficult to find since I didn’t experience it in my setup. It only happens after thing creation, so managed thing won‘t suffer from this bug after a restart. Unmanaged things (i.e. things configured in files) are always created from scratch, so they are affected any time.