Archived Forum

Hi,

i'm new to the whole Emon thing but and started with questions about MQTT -> Emon:

Sounds like the problems you have if a MQTT client is responsible of feeding the database.
There is a nice article: The missing piece between MQTT and a SQL
http://www.hivemq.com/blog/mqtt-sql-database

Look at Gotchas and Limitations:
1. What happens if the wilcard subscriber disconnects? What happens if it reconnects?
2. Is there a way to ensure that each message will be sent only once?
 

Oh dear, I assumed you are running the new Beta / RC emonPi / emonBase image with the new MQTT input service. 

The node names are created from the MQTT topic names. There must be a *slight* change of MQTT topic name after a reboot. Can you see any difference at all between the two input names? Is there a space in there or something? 

Could you post s screen grab?

I'm running the new MQTT input service, and a home built Jessie image based upon the emonpi build guide without the display / lightwave / node red and with my own openhab install in /home/pi/data/openhab

The only screen shot I have right now is where you can see the recreated topic appears at the end of the list, I'd already reconfigured everything to use it and deleted the dead one, I'll screen grab it next time it happens before I reconfigure. This might not be for a few days as everything is working right now and I'm too busy to intentionally poke it.

Its like things don't get properly saved when it reboots several times in sucession and it recovers from a corrupt input process setting by recreating the input, although the old non updating input process setttings can be read even though they don't update.

The Openhab item is Number HWCPower { mqtt="<[mymosquitto:emon/emonTx_1/power3:state:default]" }
I can't see how that would still work if the topic changes even?

It did it again this morning, and annoyingly it picked one of my more complex inputs! This happened after several reboots in succession caused by troubleshooting a relay debounce issue with Openhab, together with the usual occasional can't read rule file it seems to throw in to keep me interested. A problem that is usually cured by a couple of extra reboots.

In the picture power1 at the top has stopped updating, with power1 reappearing as a new input at the bottom that is updating

see attached

Could you try deleting the new input to see if emoncms resumes logging to the original input?

From the screen grab it looks like the Input name is identical, could you try and inspect the name carefully to see if there is something like a white space at the beginning or end?

Highlighting inputs I know have reappeared and comparing them to ones that haven't doesn't show up anything. All of them have the input name and one space afterwards.

Next time it happens I'll delete the new input and see what happens. I've already reentered the input information to get the system back up and running.

Where does it cache the mqtt inputs found information?

There shouldn't be any white spaces at the end of the input name. I think this could be where the issue is coming from. Do your mqtt topic names as shown in mqtt_sub also have the white spaces? I wonder where they are coming from?

I don't think they have spaces, I just fired up MQTT.fx which is a Java Windows MQTT Pub / Sub client and it doesn't show any spaces.

A direct copy from the log is below:

2016-02-29 09:56:16,662  INFO --- MqttFX ClientModel             : messageArrived for: emon/emonTx_1/power1
2016-02-29 09:56:16,663  INFO --- MqttFX ClientModel             : messageArrived: 563
2016-02-29 09:56:16,862  INFO --- MqttFX ClientModel             : messageArrived for: emon/emonTx_1/power2
2016-02-29 09:56:16,863  INFO --- MqttFX ClientModel             : messageArrived: 564
2016-02-29 09:56:16,864  INFO --- MqttFX ClientModel             : messageArrived for: emon/emonTx_1/power3
2016-02-29 09:56:16,865  INFO --- MqttFX ClientModel             : messageArrived: 565

As Openhab subscribes to the same topics I'm not suspecting whte spaces are in the topics, What error handing is there is the system goes down half way through a topic being received?

For example if it received a valid topic name but with rubbish in the payload due to a thread being terminated half way through the message transmission

@glyn deleting the new copy of the topic makes the old copy work again, I've had one topic recreate from Openhab on the same box so its not coming from EMONHUB

Hi,

I'm seeing the same behaviour with a customised local version of emonhub - which feeds data to emoncms with calls like:

http://emoncms.org//input/post.json?node=26&json={"L1Voltage":"235.28","L1Current":"8.76","L1VA":"2060.48","L1Po ...

Deleting the new feeds puts the old ones back into use...

http://buttersideup.com/files/duplicated-inputs.png

HTH.

Cheers,

Tim.

Could this be related to MQTT retained messages?

If the MQTT retained flag is set somewhere, undelivered messages will continue to try and get an acknowledgement, even surviving reboots...

Paul

@TimSmall are you reporting that you are getting duplicated inputs when posting data via HTTP API rather than MQTT? If so then maybe this issue is not related  derectly to MQTT

​@Paul good point, however emonhub has retain turned off by default:

https://github.com/openenergymonitor/emonhub/blob/emon-pi/src/interfacer...

@Paul I have persistence false in mosquitto.conf, which I haven't changed so hopefully this is off

@Glyn I also have log_dest file /var/log/mosquitto/mosquitto.log in mosquitto.conf, and looking at that file it has some old information in it. Is it worthwhile changing mosquitto.conf to point to something in /tmp with the read only file system?

> TimSmall are you reporting that you are getting duplicated inputs when posting data via HTTP API rather than MQTT?

Yep, just posting with the HTTP API - no MQTT. Symptoms and issue look identical otherwise.

Noticed the issue this morning when trying to debug some non-updating inputs, and then found the thread via google...

Tim.

@Kevin - That is the global setting, but I believe it is overwritten by the host software on a node by node basis.

@Glyn - I wondered if retain=False should be retain=false?

Paul