ECONNREFUSED with 0.0.0.0 address

[dmwyatt]

I'm getting messages from smartthings, but am unable to send them.

When I attempt to do so I get this in the log:

{
    "code": "ECONNREFUSED",
    "errno": "ECONNREFUSED",
    "syscall": "connect",
    "address": "0.0.0.0"
}

This is a hassio install if it makes any difference.

I'm not sure why its giving that IP address...

[Riddlr]

Same here - it all started happening when my nVidia Shield upgraded to 7.0

[dmwyatt]

Damn, I wonder if that's the problem. I'm also running the ST link on my Shield.

This morning I switched from hass.io on my rpi to docker on an ubuntu system running mosca, HA, and this bridge and I am still getting the same issue. I didn't even think about my Shield recently getting the 7.0 update...

Thats pretty sucky because if that's the case it sounds like maybe this is a Smartthings or Nvidia issue and nothing to do with the bridge.

@stjohnjohnson IIRC, you're no longer really working on this, but does this diagnosis sound correct? I'm a developer, but I don't really know how ST works...if there's anything you could point me to to start working on fixing this (if you think it might be possible) that'd be cool.

[Riddlr]

Yeah - I am certain it is due to the upgrade - I wonder if it is related to updated android security that is blocking outside communication with the hub....

[stjohnjohnson]

Hmm. If you are getting ECONNREFUSED, my guess is the SmartThings Hub sees a different MAC address and is refusing it. Double check the outgoing MAC that the network sees.

[damien67]

I confirm having the same issue after upgrading Shield to 7. MAC address unchanged. Have you guys figured this out yet? statuses update from ST to hass, but nothing from hass to ST other than the connection refused in the logs...

Tomorrow I will try to re-create the app and device handler in the ST IDE, start from scratch! Or maybe try a different port? I was on 8081 due to Kodi using 8080...

[Riddlr]

I recreated from scratch as well - no luck. I also edited the history file it creates changing 0.0.0.0:0 to my shield ip and default ST port without success. Changing the the bridge's port is something I might try...

[damien67]

So I did some nmap this morning to see which ports were opened on the Shield, and found the following ports opened: 139, 445, 8008, 8009, 9000, 9080, 6466, 6467. (Shield asleep) I gave 9000 and 9080 a try, no luck.

Interestingly enough, when starting Kodi, port 8080 is then seen opened nmap, so the port is "openable" from the inside.

I think that leaves us with 3 options:

• Open needed port at the Android OS level
• Downgrade to Shield Experience 6.x (there is a pretty good post on how to do this on xda)
• Buy a Smartthings hub not tied up to the Shield!

I have to say, all my home automation is all written in HASS, and losing ST <-> HASS communication is a big deal.

Please let me know if you find anything...I will keep working on it on my side.

[m1tca00]

Does anyone know what port needs to be opened on the Shield?

[makingwilliam]

Hello all, I am not sure if I am having the same issue or not, because I'm not sure exactly where you are finding said ECONNREFUSED. However, I have been running the bridge on a Hass.io install for the last 2 months with no issues. Sometime in the last week, either when the recent changes were committed to the code -or- from what I can tell is when the builtin Hass.io Mosquitto MQTT Broker Add-On was updated, the bridge no longer receives any updates from MQTT, it only receives them from Smartthings and that is all now. Since then I have performed over a dozen fresh installs with the same exact result and I am not sure how to determine where the loss of communication is actually occurring. I really do not want to have to get rid of the smartthings hub, as nearly all of my security sensors are smartthings and I love the direct integration with my Samsung Galaxy. That said, I would really appreciate anyone who could help me troubleshoot and get this working again.

1. Fresh Install of Debain Stretch Lite
2. Install Hassio onto pi using alternative method (I have a 3B+)
3. Install Hassio.io Mosquitto MQTT Broker Add-on
4. Install LTS version of Node.JS
5. Install smartthings-mqtt-bridge via NPM

Able to receive messages from Smartthings into the bridge AND the bridge writes the message to MQTT. So it definitely communicates with MQTT in some way!

Not able to receive messages from MQTT directly or through HA MQTT Publishing. If I use MQTT-SPY to manually update a topic, like I used to be able to do, the payload appears changed until you re-subscribe to the topic and then it reverts back to the last payload published from Smartthings.

I am also able to create and publish topics and payloads from HA or directly in MQTT which are NOT related to Smartthings and those messages are accepted and retained properly.

[Riddlr]

This is likely a MAC issue if not using the Shield Link. I read somewhere that if using docker there is come confusion on what MAC address to configure the device handler with...

---

From: thewilliambond notifications@github.com Sent: Wednesday, July 11, 2018 10:59:12 AM To: stjohnjohnson/smartthings-mqtt-bridge Cc: Riddlr; Comment Subject: Re: [stjohnjohnson/smartthings-mqtt-bridge] ECONNREFUSED with 0.0.0.0 address (#152)

Hello all, I am not sure if I am having the same issue or not, because I'm not sure exactly where you are finding said ECONNREFUSED. However, I have been running the bridge on a Hass.io install for the last 2 months with no issues. Sometime in the last week, either when the recent changes were committed to the code -or- from what I can tell is when the builtin Hass.io Mosquitto MQTT Broker Add-On was updated, the bridge no longer received any updates from MQTT, it only receives them from Smartthings and that is all now. Since then I have performed over a dozen fresh installs with the same exact result and I am not sure how to determine where the loss of communication is actually occurring. I really do not want to have to get rid of the smartthings hub, as nearly all of my security sensors are smartthings and I love the direct integration with my Samsung Galaxy. That said, I would really appreciate anyone who could help me troubleshoot and get this working again.

1. Fresh Install of Debain Stretch Lite
2. Install Hassio onto pi using alternative method (I have a 3B+)
3. Install Hassio.io Mosquitto MQTT Broker Add-on
4. Install LTS version of Node.JS
5. Install smartthings-mqtt-bridge via NPM

Able to receive messages from Smartthings into the bridge AND the bridge writes the message to MQTT. So the it definitely communicates with MQTT in some way!

Not able to receive messages from MQTT directly or through HA MQTT Publishing. If use MQTT-SPY to manually update a topic, like I used to be able to do, the payload appears changed until you log out and log back in and then it reverts back to the last payload published from Smaartthings.

I am also able to create and publish topics and payloads from HA or directly in MQTT which are NOT related to Smartthings and those messages are accepted and retained properly.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/stjohnjohnson/smartthings-mqtt-bridge/issues/152#issuecomment-404258395, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFxHA3NgjVK6199x9dxIMdpysgDHira8ks5uFjzwgaJpZM4U8ONx.

[makingwilliam]

I have checked and re-check the MAC address. I am currently using the ETH0 mac address of the raspberry pi, which is what I used before. I have also force disabled the wifi driver in my most recent attempts, that did not help either.

[Riddlr]

I installed the bridge in /etc/mqtt-bridge. In the install directory you should be able to tail events.log -n 100 right after you try change a ST device in HASS and see what it says - that is where I found the error.

Also, you can run mosquitto_sub -t +/# -v -u -P on the mqtt broker machine to view if HASS is attempting to send messages to ST.

---

From: thewilliambond notifications@github.com Sent: Wednesday, July 11, 2018 11:04:44 AM To: stjohnjohnson/smartthings-mqtt-bridge Cc: Riddlr; Comment Subject: Re: [stjohnjohnson/smartthings-mqtt-bridge] ECONNREFUSED with 0.0.0.0 address (#152)

I have checked and re-check the MAC address. I am currently using the ETH0 mac address of the raspberry pi, which is what I used before. I have also force disabled the wifi driver in my most recent attempts, that did not help either.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/stjohnjohnson/smartthings-mqtt-bridge/issues/152#issuecomment-404260079, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFxHA7evrwI3aP8I1iouqwnPODpZHTGqks5uFj47gaJpZM4U8ONx.

[makingwilliam]

@Riddlr, thanks for your help. I usually look at the bridge log using pm2 logs, since I am using it to run the bridge. The logfile only show messages from Smartthings, never anything from MQTT. However, and I think it is important to note, MQTT does receive updates manually and from both HA and the bridge (using smartthings). It appears the bridge is just not retrieving the changes from MQTT, even though it is certainly publishing changes.

As for manually publishing messages, I typically use the MQTT-Spy application. When I publish to a non-smartthings topic, it works perfectly fine as expected and retains the payload. But when I publish to a smartthings topic, the payload appears changed (but only until I lose connection or re-subscribe, in which it reverts back to the last payload published by the bridge.

[makingwilliam]

Use --update-env to update environment variables
[PM2] Applying action restartProcessId on app [smartthings-mqtt-bridge](ids: 0)
[PM2] [smartthings-mqtt-bridge](0) ✓
┌─────────────────────────┬────┬──────┬──────┬────────┬─────────┬────────┬─────┬───────────┬──────┬──────────┐
│ App name                │ id │ mode │ pid  │ status │ restart │ uptime │ cpu │ mem       │ user │ watching │
├─────────────────────────┼────┼──────┼──────┼────────┼─────────┼────────┼─────┼───────────┼──────┼──────────┤
│ smartthings-mqtt-bridge │ 0  │ fork │ 4018 │ online │ 2       │ 0s     │ 0%  │ 13.4 MB   │ root │ disabled │
└─────────────────────────┴────┴──────┴──────┴────────┴─────────┴────────┴─────┴───────────┴──────┴──────────┘
 Use `pm2 show <id|name>` to get more details about an app
root@hassio:/home/pi# pm2 logs smartthings-mqtt-bridge
[TAILING] Tailing last 15 lines for [smartthings-mqtt-bridge] process (change the value with --lines option)
/root/.pm2/logs/smartthings-mqtt-bridge-error.log last 15 lines:
/root/.pm2/logs/smartthings-mqtt-bridge-out.log last 15 lines:
0|smartthi | info: Incoming message from SmartThings: smartthings/Downstairs Hall/motion/state = active
0|smartthi | info: Incoming message from SmartThings: smartthings/Studio Office/motion/state = active
0|smartthi | info: Incoming message from SmartThings: smartthings/Bathroom/motion/state = inactive
0|smartthi | info: Incoming message from SmartThings: smartthings/Downstairs Hall/motion/state = inactive
0|smartthi | info: Incoming message from SmartThings: smartthings/Studio Office/motion/state = inactive
0|smartthi | info: Saving current state
0|smartthi | info: Starting SmartThings MQTT Bridge - v3.0.0
0|smartthi | info: Loading configuration
0|smartthi | info: Loading previous state
0|smartthi | info: Perfoming configuration migration
0|smartthi | info: Saving current state
0|smartthi | info: Connecting to MQTT at mqtt://10.0.0.199
0|smartthi | info: Configuring autosave
0|smartthi | info: Configuring API
0|smartthi | info: Listening at http://localhost:8080

0|smartthi | info: Incoming message from SmartThings: smartthings/Studio Office/motion/state = active
0|smartthi | info: Incoming message from SmartThings: smartthings/Office Lights/level/state = 7
0|smartthi | info: Incoming message from SmartThings: smartthings/Office Lights/switch/state = on
0|smartthi | info: Incoming message from SmartThings: smartthings/Studio Office/motion/state = inactive
0|smartthi | info: Incoming message from SmartThings: smartthings/Office Lights/level/state = 0
0|smartthi | info: Incoming message from SmartThings: smartthings/Office Lights/switch/state = off

[makingwilliam]

I did notice that the configuration for the Hass.io Mosquitto MQTT Broker has recently changed; however, the documentation has not been updated to include the new parameters. I also read a post from someone else having these problems who asked about websockets, although they never got a response. I am curious if this is what is preventing the updates or not.

Default MQTT Configuration (foremerly, this did not include *_websockets, when the bridge was working):

{
  "plain": true,
  "plain_websockets": false,
  "ssl": false,
  "ssl_websockets": false,
  "anonymous": true,
  "logins": [],
  "customize": {
    "active": false,
    "folder": "mosquitto"
  },
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem"
}

[damien67]

Alright...for all of you with the Shield TV Link, I 100% confirm that the recent Shield update broke the bridge. Because of the frustration of not having any of my automation running, I simply decided to purchase another v2 hub (Amazon had a refurbished one + 2 sensors + outlet + motion sensor for $110). If it doesn't work, return, if it works, great, at least I don't depend on the Shield anymore.

So I just installed it, paired the hub to my Smartthings app, installed the device in the IDE on the new hub (used port 8084 to avoid confusion), unpaired a z-wave thermostat and a zigbee light from the old hub, paired them to the new one, configured the smartapp in Smartthings app, change port in HASS addon, voila.

Both devices controllable without issue from HASS, no error in the logs.

I considered getting a zwave/zigbee stick to avoid getting a hub relying on the cloud, but I have to say that I have been a very happy smartthings user. It is solid, easy and practical, and Google Homes in my house work flawlessly with it. The mqtt solution prior to this Shield upgrade was solid as well! never really had issues. Home Assistant on the side is my playground, I love tinkering in it, writing new automations, troubleshooting them etc.

I am not sure if Nvidia or Samsung will fix this, but if you want immediate resolution, this one may be the only one. I guess the $10 promotional Shield Link locked me as a Smartthings customer!

[Firemogle]

I thought I was going crazy trying to fix this until I finally found this bug thread, also on nvidia shield, also noticed LAN devices died after the update.

Looks like Im off to ebay to get a v2 standalone hub

[makingwilliam]

Solved my problem, but I'm not sure if it relates to any of you. When I originally setup my raspberry pi, I was not running it dockerized like the present Hass.io setup. So, initially I found my MAC address through my routers client list, which worked fine. Now that I have moved to Hass.io, even though my physical MAC address is the same and hasnt changed, when I go into the pi and run ifconfig I get a completely different mac address for eth0. I input that address instead, now everything is working!

[wklink]

Just saw this: https://forums.geforce.com/default/topic/1090613/shield-tv/shield-experience-7-2-1-release/

Haven't updated myself yet, but included in this update is:

• Resolves port blocking issue with SmartThings on SHIELD

[Riddlr]

Looks like this latest update has fixed the issue for me...

[wklink]

Made the update and can confirm that this is resolved for me, too,

[damien67]

I guess I’ll keep the link as a backup solution in case my hub dies!! Good news though.

[stjohnjohnson]

Glad everyone is resolved!