AutoEvents fail when service is enabled without a peer MQTT application running about device-mqtt-go HOT 8 CLOSED

Yea, I think that's the best approach. There should be a section of the top-level README that describes how to add AutoEvents.

Anyways for my demo I'm using my own configuration and device profile.

from device-mqtt-go.

@tonyespy Do you follow the doc to create a mock device?
In the current design, if you want to execute the read command, the MQTT device should subscribe CommandTopic and send the response to the ResponseTopic.

// 2. Receive the reading request, then return the response
// 3. Receive the put request, then change the device value
subscribe( "CommandTopic" , (topic, val) => {
    var data = val;
        if (data.method == "set") {
        message = data[data.cmd]
    }else{
        switch(data.cmd) {
            case "ping":
              data.ping = "pong";
              break;
            case "message":
              data.message = message;
              break;
            case "randnum":
                data.randnum = 12.123;
                break;
          }
    }
    publish( "ResponseTopic", JSON.stringify(data));
});

Otherwise the device reading should come from async value.

from device-mqtt-go.

No, I didn't create a mock device per the documentation as the documentation isn't linked from the top-level README, nor does the top-level README explain how this device service is supposed to work (see issue #86 for suggestions on how this page needs work). I'll update the description to remove the bit about the command errors, and will open a new issue for those if needed.

My suggestion would be to remove the AutoEvent from the default configuration file, as if you start the device service and haven't configured a remote MQTT application to handle incoming commands via the topic "CommandTopic" and reply via "ResponseTopic", then you'll just see a steady stream of AutoEvent failures in the service log output.

from device-mqtt-go.

It turns out the snap is using the configuration.toml from examples, not the default configuration.toml (which doesn't have any AutoEvents defined).

I'll discuss with @anonymouse64, perhaps we should only be installing the default configuration file?

Needless to say, this is certainly something that should be covered in the top-level README file.

from device-mqtt-go.

@tonyespy we decided to switch the snap to use the example configuration.toml by default because that was easier for demos and for the snap to be "usable". Since we don't have edgexfoundry/device-sdk-go#342, it's somewhat complicated to switch what configuration.toml file you are using, so making the default one "work" easiest is desirable.

Perhaps we could just modify the example configuration.toml to not have AutoEvents instead.

from device-mqtt-go.

Why we need to remove the AutoEvents from the example configuration.toml ?
I though it's just an example file. User still need to customize their configuration.toml to connect the MQTT broker and add predefined device.

from device-mqtt-go.

@weichou1229 yes it is an example file, but IMHO examples should be runnable with minimal changes, and to use AutoEvents a user would need to configure a lot more than just installing an MQTT broker.

However, if you wanted to leave an actual configuration.toml with AutoEvents defined in it, it would be nice to have a separate configuration.toml file without AutoEvents that we can use in the snap to make the snap easily work as a demo/reference platform. For example, with the current configuration.toml you can test everything out with just:

# install snaps
sudo snap install edgex-device-mqtt --channel=edinburgh/beta
sudo snap install edgexfoundry --channel=edinburgh/beta
sudo snap install mosquitto

# wait for things to startup
sleep 10

# start device-mqtt
sudo snap start --enable edgex-device-mqtt

# send a command via MQTT with mosquitto_pub to device-mqtt
mosquitto_pub -t DataTopic -m '{"name":"MQTT test device","cmd":"randfloat32","randfloat32":"1.2"}'

# wait for it to propogate through the system
sleep 5

# get the reading from core-data
curl -s localhost:48080/api/v1/reading | jq

If we don't have a configuration.toml that "just works" in the snap, then folks have to configure their own, even if all they are trying to do is demonstrate how device-services work and how to use device-mqtt.

from device-mqtt-go.

@anonymouse64
Ok, I get it now, thanks. I discussed with Cloud, we prefer to create another file for the different use case.
Could you please open PR to create a separate configuration file for snap?

from device-mqtt-go.