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.