Giters

stefanwichmann / kelvin

Kelvin - The hue bot

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Kelvin panics when there is no bridge

prfalken opened this issue · comments

commented

Testing kelvin in a place where there is no hue equipment at all, kelvin stops with a panic :

INFO[2019/06/04 11:35:54] ⚙ Default configuration generated
WARN[2019/06/04 11:35:57] Bridge discovery failed
INFO[2019/06/04 11:35:57] 🌍 Location not configured. Detecting by IP
INFO[2019/06/04 11:35:57] 🌍 Detected geolocation: Nantes (47.2173, -1.5534)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x12a6442]

goroutine 1 [running]:
net/http.(*Client).deadline(0x0, 0xc0000a0040, 0x1ffffffffffff, 0xf8)
	/usr/local/Cellar/go/1.12/libexec/src/net/http/client.go:187 +0x22
net/http.(*Client).do(0x0, 0xc0001f8000, 0x0, 0x0, 0x0)
	/usr/local/Cellar/go/1.12/libexec/src/net/http/client.go:527 +0xab
net/http.(*Client).Do(...)
	/usr/local/Cellar/go/1.12/libexec/src/net/http/client.go:509
net/http.(*Client).Get(0x0, 0xc0003d7600, 0x12, 0xc0003d7600, 0x12, 0x0)
	/usr/local/Cellar/go/1.12/libexec/src/net/http/client.go:398 +0x9e
github.com/stefanwichmann/go%2ehue.(*Bridge).get(0x1902e20, 0x14d7fb9, 0x7, 0x1434440, 0xc0001d6058, 0x197)
	/Users/prfalken/go/src/github.com/stefanwichmann/go.hue/bridge.go:88 +0x6f
github.com/stefanwichmann/go%2ehue.(*Bridge).GetAllLights(0x1902e20, 0x0, 0x0, 0x0, 0x0, 0x0)
	/Users/prfalken/go/src/github.com/stefanwichmann/go.hue/bridge.go:215 +0x77
main.(*HueBridge).Lights(0x1902e20, 0x0, 0x0, 0x0, 0x0, 0xc000024500)
	/Users/prfalken/go/src/github.com/stefanwichmann/kelvin/bridge.go:88 +0x45
main.main()
	/Users/prfalken/go/src/github.com/stefanwichmann/kelvin/kelvin.go:87 +0x4d2

Kelvin detects that there is no bridge, but then it probably tries to call Lights() on the bridge and panics.

commented

Would you prefer to make it retry indefinitely until it finds a bridge or shut down properly after X retries ?

commented

Good catch!

We only log a warning if the initial bridge discovery fails. This could probably be a fatal error as Kelvin can't provide any of its functionality without a bridge.

If there is a network issue at runtime and the bridge goes offline for a certain time, Kelvin should already recover nicely once the bridge is back up.

If we introduce a retry also on startup it should probably be an endless loop... won't help with testing though. Opinions?

commented

Yes, imho an endless loop would be better. I have Kelvin running on a raspberry pi here, and I would like to start the server and know that it's waiting until I turn on the bridge.