TemperatureSensor stopped updating value

WebThings
#1

Hello,

can someone please explain how the GW decides when to poll for property value?

One of my TemperatureSensors value stoppped updating and is stuck on 21C (Kotel).

2020-01-30_07-20

Others running from the same device but different URL works fine. I can see them updating in the console log.

2020-01-30 05:53:20.838 INFO   : thing-url: getValue for property CHO1 for: Podlahovka returning 21.4
2020-01-30 05:56:01.499 INFO   : thing-url: getValue for property CHO1 for: Podlahovka returning 21.5
2020-01-30 05:56:33.396 INFO   : thing-url: getValue for property CHO1 for: Podlahovka returning 21.4
2020-01-30 05:56:50.298 INFO   : thing-url: getValue for property CHO1 for: Podlahovka returning 21.5
2020-01-30 05:57:06.284 INFO   : thing-url: getValue for property CHO1 for: Podlahovka returning 21.4
2020-01-30 06:00:12.367 INFO   : thing-url: getValue for property STATUS for: Podlahovka returning heating
2020-01-30 06:35:23.540 INFO   : getValue for property CHO1 for: Podlahovka returning 21.4
2020-01-30 06:35:23.540 INFO   : getValue for property STATUS for: Podlahovka returning heating
2020-01-30 06:35:23.545 INFO   : getValue for property STATUS for: Radiátory returning off
2020-01-30 06:35:23.546 INFO   : getValue for property CHO2 for: Radiátory returning 20.9

I can check the property value on the URL works ok and is up-to-date.

http://rpi/iot/kot_prop.php?id=KOT1

{"KOT1":26}

Thanks,

Tomas

#2

If your webthing library/server supports WebSockets, the devices are not polled, as propertyStatus messages should be sent through the WebSocket.

If WebSockets are not supported, properties are polled every 5 seconds by default. However, that can be configured in Settings -> Add-ons by clicking Configure on the “Web Thing” add-on entry.

#3

I do not use Websockets. And that one Thing property is not updated seem like a bug in the Gateway to me. I could provide some info if needed - the Thing is still stuck in the Gateway.

Tomas

#4

Is there any way you could give me access to your device, or to the code you’re using so that I can test?

#5

I am afraid that this is not possible, but I can run any test against the Thing or on the Gateway.

#6
  1. Can you run Wireshark or tcpdump or something and ensure that the property is being polled every 5 seconds?
  2. Can you show me the full thing description from your device?
#7

  1. Unfortunatelly there was poweroutage today and the Gateway was shutdown but I will do tcpdump next time it happens.

  2. May be it is not correct but it was working fine for some time with this version of GW.

    {
    “@context”: “https://iot.mozilla.org/schemas/”,
    “@type”: [“TemperatureSensor”],
    “id”: “http://rpi.lan/iot/kot.php”,
    “title”:“Kotel”,
    “properties”: {
    “KOT1”: {
    “@type”: “TemperatureProperty”,
    “type”: “number”,
    “unit”: “degree celsius”,
    “title”: “Komín”,
    “readOnly”: true,
    “links”: [{“href”: “/iot/kot_prop.php?id=KOT1”}]
    }
    },
    “events”: {
    “overheated”: {
    “@type”: “OverheatedEvent”,
    “type”: “number”,
    “unit”: “degree celsius”,
    “title”: “Přetopeno”,
    “links”: [{“href”: “/iot/kot_evnt.php?id=OVERHEATED”}]
    }
    },
    “links”: [
    {
    “rel”: “properties”,
    “href”: “/iot/kot_prop.php”
    },
    {
    “rel”: “events”,
    “href”: “/iot/kot_evnt.php”
    }
    ]
    }

#8

Ok, the thing description looks fine. Let me know when you get around to checking wireshark/tcpdump.

#10

OK, it got stuck again - the same thermometer.

It should be reading http://192.168.1.120/iot/kot_prop.php?id=KOT1

Which works from browser ok with actual data:

{"KOT1":73}

Same as it is reading

http://192.168.1.120/iot/rad_mode.php and others.

Thanks,

Tomas

00001.pcap.zip (438.4 KB)

2020-03-26_22-07
2020-03-26_22-07720×593 27.6 KB

#11

Hmm, strange. It appears to be polling 4 other properties, but not KOT1. Can you attach your gateway log from when this started happening? You can access it in the UI via Settings -> Developer -> View Internal Logs.

#12

It seems that it started when the RaspberryPi (rpi.lan aka 19.168.1.120) was restarted by the watchdog because it got stuck (I do not know yet why this happens but configured the watchdog to restart it automatically) around 2020-03-24 23:15.

But there is one entry on 2020-03-25 22:13 but I have not idea if the value was correct at that time.

run-app.log.zip.zip (18.5 KB)

#13

I’m unsure what your setup is like, but it seems like maybe the Kotel device is no longer being advertised after your Pi restarts.

#14

What does it mean “being advertised”? The thing description is still available from browser when opening http://rpi/iot/kot.php

{
  "@context": "https://iot.mozilla.org/schemas/",
  "@type": ["TemperatureSensor"],
  "id": "http://rpi.lan/iot/kot.php",
  "title":"Kotel",
  "properties": {
    "KOT1": {
      "@type": "TemperatureProperty",
      "type": "number",
      "unit": "degree celsius",
      "title": "Komín",
      "readOnly": true,
      "links": [{"href": "/iot/kot_prop.php?id=KOT1"}]
    }
  },
  "events": {
    "overheated": {
      "@type": "OverheatedEvent",
      "type": "number",
      "unit": "degree celsius",
      "title": "Přetopeno",
      "links": [{"href": "/iot/kot_evnt.php?id=OVERHEATED"}]
    }
  },
  "links": [
    {
      "rel": "properties",
      "href": "/iot/kot_prop.php"
    },
    {
      "rel": "events",
      "href": "/iot/kot_evnt.php"
    }
  ]
}
#15

It seems to me the RaspberryPi works ok - I have my own interface also running there and it works ok. I think the issue is in the Gateway that something gets in the wrong state when it cannot connect to the rest api and does not recover after its available.

2020-03-24 23:15:48.937 INFO   : thing-url-adapter: getValue for property KOT1 for: Kotel returning 62
2020-03-24 23:17:19.265 INFO   : thing-url-adapter: Failed to poll device: FetchError: request to http://rpi.lan/iot/rad_prop.php?id=CHO2 failed, reason: connect ETIMEDOUT 192.168.1.120:80
2020-03-24 23:17:42.817 INFO   : thing-url-adapter: Failed to poll device: FetchError: request to http://rpi.lan/iot/rad_prop.php?id=TARGET failed, reason: connect EHOSTUNREACH 192.168.1.120:80
2020-03-24 23:17:47.826 INFO   : thing-url-adapter: Failed to poll device: FetchError: request to http://rpi.lan/iot/rad_prop.php?id=TARGET failed, reason: connect ECONNREFUSED 192.168.1.120:80
2020-03-24 23:18:10.291 INFO   : thing-url-adapter: getValue for property CHO2 for: Radiátory returning 21.6
#16

Out of curiosity, what version of the gateway are you using?

#17

Currently I am using latest 0.11.0 from debian package. But when I reported this it seems I was using 0.10.0.

Isn’t there some tool for javascript to dump current state of the process like jstack for Java or procdump to analyze the state of the threads - what function are there waiting or something?

#18

You’d need to attach a debugger to the Node.js process running the add-on.

#19

Could you give me some hints or link please? I have no idea where to start - what add-on?

Thanks

#20

You’ll need to edit ~/mozilla-iot/gateway/build/gateway.js. Look for the following:

        nodeLoader: `node ${path.join(UserProfile.gatewayDir,
                                      'src',
                                      'addon-loader.js')}`,

Add an --inspect flag as follows:

        nodeLoader: `node --inspect=0.0.0.0:9229 ${path.join(UserProfile.gatewayDir,
                                      'src',
                                      'addon-loader.js')}`,

After that, disable all add-ons except the “Web Thing” add-on, then restart the gateway as follows:

sudo systemctl restart mozilla-iot-gateway

Then, you can attach a debugger from another machine. See here for info: https://nodejs.org/en/docs/guides/debugging-getting-started/