Are you sure that ‘home’ is in the Hub field and not the location field? My biggest trouble was solved by getting the device fields filled in properly.
[quote=“JamesH, post:20, topic:4969”]
do you expect it to be set by the device code?[/quote]
The device code does set it, but I just wanted to make sure it was setting it correctly.
Both the location and hub field say ‘home’ – my hub is called ‘home’. The forum won’t let me post a picture, so here’s the device info from the ‘my devices’ page:
Raspberry Pi Device Raspberry Pi
Name Raspberry Pi
Label Raspberry Pi
Type Raspberry Pi
Version Published
Device Network Id 0A0001E1:1F40
Status INACTIVE
Hub Home
Last Activity At 2014-11-12 3:45 PM UTC
Date Created 2014-11-12 5:57 AM UTC
Last Updated 2014-11-12 6:19 AM UTC
Data No data found for device
Current States switch: off
Preferences (edit) IP Address: 10.0.1.225
Port: 8000
Username: webiopi
Password: webiopi
Events List Events
In Use By SmartApps SM for RPi
Thanks.
Ah, OK – then I guess I should unset it, and see if the code will actually set it.
So I removed the device, and re-installed it. After running the code (pressing ‘refresh’), the deviceNetworkId doesn’t show up in the Devices page on the IDE.
And just to be extra-sure…
private setDeviceNetworkId(ip,port){
def iphex = convertIPtoHex(ip)
def porthex = convertPortToHex(port)
def dni = "${iphex}:${porthex}"
device.deviceNetworkId = dni
log.debug "Device Network Id set to $dni"
}
And the code gets run:
12:45:16 PM PST: debug Device Network Id set to 0a0001e1:1f40
12:45:16 PM PST: debug Executing ‘refresh’
But no packets.
Thanks…
I’m not sure what else it could be. I know that @scottinpollock had issues encoding his port number in order to send the command correctly. Other than that, I don’t know what else to try.
Thanks for your help.
I’ve seen a few other posts about problems with leading zeroes, but that doesn’t seem to be the problem here. Since I can use wireshark to monitor the traffic to/from the hub, I changed the IP to a 192.168.x.x address, but still no packets.
I seem to be having the exact same issue as you. On this several days and wanting to pull my hair out.
Is your service running on your Pi?
@NickW, @Garnet - The firmware on my hub seems rather old, but the app thinks it’s up to date. Can you tell me what version you have?
My hub has this – the last-updated date is nearly a year ago.
Firmware Version 000.010.00246
Last Updated 2013-11-18 3:00 AM UTC
Thanks,
James
Firmware Version: 000.011.00603
Date created & updated: 2014-06-28
Thanks – then I suspect my problem is the ancient firmware.
Looks like the last firmware update was an hour after I first created the hub. So basically it’s never updated:
Firmware Version 000.010.00246
Date Created 2013-11-18 2:00 AM UTC
Last Updated 2013-11-18 3:00 AM UTC
Any ideas how to force an update? I could try deleting the hub and starting again, but I don’t want to lose all the setup.
@RobM – yes, the service is running on the Pi, I can verify that it responds by sending the POST request with telnet from a mac (see higher up in the thread).
I would try emailing support.
@JamesH - I have Firmware Version 000.011.00603 which appears to be the same @NickW.
Maybe that is the issue, and doesn’t seem like a risk to try. Good Luck and let us know.
Well, it worked! Then I broke it again somehow.
The hub had not updated from 000.010.00246, as shown in the ‘My Hubs’ page of the IDE.
When I attempted to update from the iOS app, it said 'your hub is up to date’
After turning on the extra logging events under Support->Help Us Debug, I saw at least one failed firmware update
Contacted support, they pushed an update to:
Firmware Version 000.011.00705
They also asked me to power cycle the hub, and force-quit iOS app
Deleted the existing Device and Device Type, went through the setup again
Refresh -> ‘an unexpected error occurred’
Set Device Network Id manually via the IDE, to 0a0001e2:1f40
Refresh -> worked … success!
So now, being such an engineer, I decided to do it all over again to get the exact steps to post. And now it doesn’t work any more.
The POST request gets sent to the Pi, the Pi responds, but the ‘parse’ function is never called in the device handler.
Here is the interaction from my packet sniffer:
===================================================================
/usr/local/bin/tshark -r request-response.pcap -q -z follow,tcp,ascii,1
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 1
Node 0: 10.0.1.10:2346
Node 1: 10.0.1.226:8000
152
POST /macros/getData HTTP/1.1^M
Accept: /^M
User-Agent: Linux UPnP/1.0 SmartThings^M
HOST: 10.0.1.226:8000^M
Authorization: Basic d2ViaW9waTp3ZWJpb3Bp^M
^M
17
HTTP/1.0 200 OK^M
143
Server: WebIOPi/0.7.0/Python3.2^M
Date: Fri, 14 Nov 2014 15:39:22 GMT^M
Cache-Control: no-cache^M
Content-Type: text/plain^M
Content-Length: 93^M
^M
93
{
“disk_usage”: 18.9,
“mem_avail”: 291.7,
“cpu_temp”: 48.2,
“cpu_perc”: 0.6
}
I’ve tried deleting and recreating multiple times, even with different names, but it doesn’t want to work for me.
OK – back working again. I deleted the ‘Device’ and ‘Device Type’ entries again, and re-created. This time however, I moved the Pi to a different static IP, and now it works, hooray!
So, I suspect a problem routing the response message via the SmartThings cloud to the handler:
Maybe I’ll try breaking it again later.
In the meantime, thanks for the help…!
I’m glad you’ve got it working and thanks for the feedback.
I’ve updated the GitHub readme with reference to the firmware version checking and added a troubleshooting section.
One other minor detail – I had to add ‘from time import sleep’ to the top of the python file. Otherwise it complains about the ‘sleep(0.1)’.
Well this is entertaining – it seems that there’s a problem with re-use of Device Network Ids.
As I mentioned above, after deleting everything and starting from scratch, I had problems until I moved the static IP.
Next, I kept the ‘Device Type’ in place and deleted the ‘Device’. After re-installing, the app wasn’t working any more. But this time, I saw logs from two devices … the old (zombie) one and the new one!
Note that there are two ‘Raspberry Pi’ instances, and the request and response messages have different values for the key on the left.
Clicking the first ‘Raspberry Pi’ shows the sender (new Device):
Clicking the second ‘Raspberry Pi’ shows the responses being processed by the old (zombie) Device:
So… I have to conclude that the response message received by the TCP/IP stack on the hub is being routed to the first Device that registered the DNI, and the routing doesn’t get updated when that device is deleted. And it doesn’t get updated when the new Device runs (perhaps related to the need to set the DNI manually in the IDE).
When I changed the port from 8000 to 8001, it still sends the responses to the zombie, until I manually changed the DNI in the IDE. Then it all works again, because the DNI is different, never used before:
So there is definitely a problem with setting the device network id in this code, and maybe a problem with the SmartThings cloud as well.
Repository updated. Thanks for the feedback.
I wonder if we need to implicitly delete the old device during the uninstall. See the bottom of this page under “Implicit Removal of Child Devices”. Maybe we need to make the Raspberry Pi app as a device manager app instead similar to the Sonos (connect) SmartApp.
