Encountering an issue in which a device configured with the homie convention goes offline eventually. I get notified after I try and send a message to it.
Here is the rule:
rule 'Update Chomecast Track'
when Item ChromecastStatusTrack changed
then
logInfo("Nuvo", "Updating Nuvo Chromecast Track")
sendCommand(Nuvo_Source_5_Display_Line_1, ChromecastStatusTrack.state)
end
When that rule gets called, I get the following error in my openhab.log:
2019-01-07 06:39:47.923 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Update Chomecast Track': An error occurred during the script execution: Could not invoke method: org.eclipse.smarthome.model.script.actions.BusEvent.sendCommand(org.eclipse.smarthome.core.items.Item,org.eclipse.smarthome.core.types.Command) on instance: null
So the item is now null, for some reason.
I see this in the event.log at the same time:
2019-01-07 06:39:47.893 [hingStatusInfoChangedEvent] - 'mqtt:homie300:mosquitto:nuvo' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): No connection or readOnly channel!
Why would the connection go away? I am assuming the MQTT client reconnects if an error occurs. If I restart everything, things work again for a while.
Your homie device should NOT send a $stats/interval, if it NOT update its stats including the $stats/interval topic within the set time-frame. The current binding code will otherwise assume the device disappeared and put the Thing OFFLINE.
I assume that is the problem.
Btw: I will remove that code as soon as I find time.
Hi @David_Graeff -
Thanks for chiming in (as always) and your contributions to Openhab.
In this particular case I am not sending any $stats objects at all. I just double checked the broker and non are set. From what I can, there is only one location in the code that would have the āNo connection or readOnly channel!ā error. Which is line 324 of src/main/java/org/eclipse/smarthome/binding/mqtt/generic/internal/generic/ChannelState.java
it looks like that is only thrown if the connection is null or the channel is readOnly. Would a heartbeat timeout trigger either of those?
hi, Iām using openhabian2.4 and homie convention+esp32 ,now iām able to set auto discovery for my esp devices in openhab but i want to control my devices from Alexa, so for that i have to set tags ( [ āLightingā ], [ āSwitchableā ]..) but i donāt know how to set tags through homie convention ??
The following topics are published as retained messages to the broker (from esp):
Can you help me out with a sample extension, so that i can try writing the extension myself. or if there is any other way to make Alexa detect my devices other than rest API.?
@David_Graeff Can you explain section 5 of the Homie 3 spec a little moreā¦
> ## Timings
>
> As soon as a device starts to publish any Homie related topic, it MUST finish with all topics within a timeframe of 500ms. Controllers should assume the default for topic values not received within this timeframe.
Does this mean that all nodes must supply all their details within that 500ms of the device starting up or the defaults will be applied ? This could be hundreds of nodes potentially.
Iām looking at an app that is sending a lot of nodes (50+) and it does not manage to complete the sending of that information in that time - in fact its an order of magnitude adrift based on the cpu power it has. Is there a way around this as Iām thinking itās just not possible in this case ?
What I am seeing is the device comes online but fairly quickly goes offline on a timeout but the stats are being provided bang on the interval set. OH shows a device did not send heartbeat in timeā error, maybe I should increase the expected interval to less than the stats.
Also when trying to control a node I am getting a topic is read only which I think results from a default $settable being applied. MQTT shows the correct ātrueā value in $settable. All nodes do appear in discovery.
Lastly .. is a topic allowed to contain a whitespace character which is valid in MQTT but is not specifically mentioned in the Homie 3 spec ?
Yes it doesnāt mention whitespace specifically but I was guessing that - unfortunate - not sure why itās not allowable.
Iāll look at that other github timing issue post..
It seems it has some ambiguity .. David commented ā¦ āDoesnāt the section say half a second without any input? As long as you keep sending data, everything is alright.ā
ā¦not sure what the outcome is .. but I know this device is taking nearly 10 secs. But it doesnāt look like that is the reason for going offline. Maybe Iām breaking things with some topics having whitespace in them. Iāll try eliminating that first.
The mqtt binding (home controller) requires a timeout. Otherwise if the device dies on the other end, we would have a dangling Thread that is never forcefully killed. Thatās the reason why I convinced the Homie community to add a timing paragraph.
But yeah, it doesnāt work for slow devices that well. I guess, I should rely on $state and have a very generous timeout in the binding instead.
So the integration with Homie 3 that this guy has tried to implement (one of the first I believe outside of esp8266) canāt be done until 2.50 or is this retrospective to people adding/updating the MQTT 2.4 binding ?
I donāt understand if this is a change to the spec or a change to the plugin code ? Looks like the former so why is this failing currently ? stats are updated within 50s against an interval of 60s and yet it times out on a missed heartbeat.
There is a fixed timeout of 1.5 seconds for the entire Homie tree and a 200ms timeout for a single property sub-tree. Those timeouts are quite low for slow devices.
The homie tree takes over 10 secs to populate into MQTT - am I still stuffed ? (There are no long pause between nodes - just a lot of them). It comes from trying to expose one controller with all itās devices to another.
