Bug Filed on 04-06-2016: Dashboard Panic

What dashboard are you using? Web, Android

What OS? Jessie

What Model Pi? pi 2 /8gb class 10 sd /ethernet

Please describe the bug / issue. Attaching any relevant screenshots would be very helpful!

This is my second clean installation of cayenne (flashed fresh sd image, created new account) as the previous(with a different account) crashed in a horrible way beyond being recoverable. A lot of bogus sensors appeared out of nowhere, impossible to remove by any means. Resetting the dashboard did nothing usefull beyond removing the entries I have created and left behind all the uselles stuff.

As of this morning several pages of new erroneous sensors have appeared in the dashboard.

I have a vague suspicion that the android app might be causing this or contributing somehow. Whenever I try to access my pi while being offline things seem to get thing mixed up… at least that’s my impression because i have tested the whole setup for several days in my office and watched over it performing flawlessly until being deployed to the field (the boiler room) where all the funny stuff begun.

Edit: Flashing new sd with jessie now for the third time

web interface sceenshots

This is the second time this happens with the same hardware configuration (Rpi2 class10 8gb sd Eth0)

Troubleshooting efforts…
All sensors are readily accessible any time with cat /sys/bus/w1/devices/28-*/w1_slave command(returns true temp values and YES) and ls command in /sys/bus/w1/devices yields the expected list of sensors i have installed and cataloged. No CRC or name errors whatsoever so I suppose my meticulously checked wiring is OK.

More problems :frowning:
The relays have gone unresponsive as well, but this might be caused since I have changed the starting values of the gpio pins used from /etc/webiopi/config … I think I shouldn’t do that as now the relays behave strangely (They are not switching on simultaneously when restarting after a reboot but rather in a rattle fashion) even after restoring the original config values. (#All commented).

Is there any way to reset my account and start all over again after a clean install or should I proceed with a new account?
How can I bind the gpios to certain starting IN/OUT LOW/HIGH states safely, if not through webiopi/config?

Thanks in advance for your combined effort, I would love to participate to your project’s debugging by providing feedback and maybe ideas.Keep up with the good work!

Hey gamoxristos,

How have you been doing new installations of Cayenne? …Jessie should be re-installed on the SD card (as a new image) and then the new Cayenne installation can be installed. My fear is you installed a new installation of Cayenne onto an SD card that had a previous version of Cayenne installed on it. (side note: we are coming up with a way to uninstall Cayenne completing from the sd card so you will not have to write new images every time)

You shouldn’t have to create an account again, you can generate a new Cayenne install by adding another Pi to your account. (View image below)

We are working on a way to allow this configuration. It was also reported here How do I save the GPIO setup? - #3 by bestes

Thanks for working with us on this!


Thanks for the reply,
I installed cayenne on a fresh image of jessie every time I repeated the proccess of making a new account to eliminate any possibility of residual activities.
I am flashing a new image right now to start again. Your advice is that i should log in to this account instead of creating a new one? I have the impression that with my previous account aaronis89 my dashboard was full of the bogus sensors in spite of the new pi I introduced to cayenne.
Let me know and I will adjust my course of action accordingly.
PS: I dont know if my login information would be of any use to help you in debugging.
Thanks again, looking forward to get some direction.

Are you adding devices directly to the webiopi config file on the Pi? Or are you using the GUI dashboard to add the devices?


Nope I did everything through cayenne GUI and dashboard and after completing everything I have only changed the GPIO IN/OUT 0/1 values in /etc/webiopi/config [GPIO] and [~GPIO] (reset) to set the desired start and reset values for the desired pins.

Hmmm. Okay, thanks for all the info.

Can you PM me your Cayenne account details that’s experiencing this issue? If you’d rather not, that’s totally okay.


Quick question how many 1 wire sensor do you actually have connected ?
can you provide the result of that command
ls -l /sys/bus/w1/devices

The ls -l /sys/bus/w1/devices gives expected and normal results including only the installed sensors. I cant copy paste what ls -l /sys/bus/w1/devices returns because the sensors are still installed in the boiler room

Now I am using 28-0215722916ff which is connected now along with 28-02157206feff (exchange) for troubleshooting purposes.

Below are the id’s of the 6 ds18b20 I have originally installed in the dashboard.

28-02157206feff exchange
28-0215722830ff boiler top
28-0215723352ff boiler mid
28-0315904972ff boiler low
28-800000014f3b BUFFER TOP
28-800000014713 BUFFER_LOW

I hope that helped, thanks

Thanks that help a lot, so we found 2 issues
the first one, there is sometime 84 sensors detected on your pi instead of 6
the second one is related to the packet size with 84 sensors. we are fixing it.

in order to solve the first one, can you please send the following file


Hi again,
I renamed it to *.txt so I can upload it directly.
Let me know if I can help any other way,

devices.json.txt (17.2 KB)

Would an edit of this file result in a cleanup of the bogus sensors or is generated by another proccess and it is pointless?

OK, that explains a lot…

Please delete it and restart webiopi
sudo rm /etc/webiopi/devices.json
sudo service webiopi restart

that should fix your issues, redetect sensors, but you will have to reset your dashboard and readd your relay widgets. let us know if you still have any trouble.

1 Like

perfect! I will proceed and I ll let you know as soon as its ready…

Works like a charm!!! You nailed it!!! devices.json was what I needed to get rid off and regenerated. Moreover everything appears to be more responsive and faster after the reset. Now the moment of truth will be when I will reconnect through the android app as I had formed the impression it was the problem causing factor… I will try to delay using it for a couple of days to get things clear…
Thanks again, I 'll keep you updated!

Hello again ! There seems to be the same problem again. Multiple sensors appear again…
I need to turn off auto discovery for ds18b20 in order to be able to troubleshoot… Can you help me disable this feature?
Already tried to remove the erroneous entries with sudo nano /etc/webiopi/devices.json (removed all unwanted entries) and sudo service webiopi restart, but nothing was achieved this way.
Maybe I have skipped something in the proccess. My next approach will be to remove devices.json and paste the following in the new file that will be generated… ???

{“description”: “EXCHANGE”, “name”: “021572068bff”, “args”: {“slave”: “28-021572068bff”}, “status”: 1, “origin”: “rest”, “device”: “DS18B20”, “type”: [“Temperature”]},
{“description”: “BOILER_TOP”, “name”: “0215722830ff”, “args”: {“slave”: “28-0215722830ff”}, “status”: 1, “origin”: “rest”, “device”: “DS18B20”, “type”: [“Temperature”]},
{“description”: “BOILER_MID”, “name”: “0215723352ff”, “args”: {“slave”: “28-0215723352ff”}, “status”: 1, “origin”: “rest”, “device”: “DS18B20”, “type”: [“Temperature”]},
{“description”: “BOILER_LOW”, “name”: “0315904972ff”, “args”: {“slave”: “28-0315904972ff”}, “status”: 1, “origin”: “rest”, “device”: “DS18B20”, “type”: [“Temperature”]},
{“description”: “BUFFER_LOW”, “name”: “800000014713”, “args”: {“slave”: “28-800000014713”}, “status”: 1, “origin”: “rest”, “device”: “DS18B20”, “type”: [“Temperature”]},
{“description”: “BUFFER_TOP”, “name”: “800000014f3b”, “args”: {“slave”: “28-800000014f3b”}, “status”: 1, “origin”: “rest”, “device”: “DS18B20”, “type”: [“Temperature”]},
{“description”: “BUFFER_TOP graph”, “name”: “vp8xtK0pv9qEMJMu”, “args”: {“slave”: “28-800000014f3b”}, “status”: 1, “origin”: “rest”, “device”: “DS18B20”, “type”: [“Temperature”]},
{“description”: “BOILER_TOP graph”, “name”: “zzzHwnG0Jrp1oysF”, “args”: {“slave”: “28-0215722830ff”}, “status”: 1, “origin”: “rest”, “device”: “DS18B20”, “type”: [“Temperature”]},
{“description”: “HEAT_PUMP 3 / 19”, “name”: “xsrFxsqywzytJDqq”, “args”: {“channel”: 19, “invert”: false, “gpio”: “GPIO”}, “status”: 1, “origin”: “rest”, “device”: “RelaySwitch”, “type”: [“DigitalActuator”]},
{“description”: “Relay Switch 6 / 16”, “name”: “DLpDzzxtJwIvuJ7E”, “args”: {“channel”: 16, “invert”: false, “gpio”: “GPIO”}, “status”: 1, “origin”: “rest”, “device”: “RelaySwitch”, “type”: [“DigitalActuator”]},
{“description”: “HEAT_PUMP_CIRC 4 / 13”, “name”: “FG2JuoJos8IznKDs”, “args”: {“channel”: 13, “invert”: false, “gpio”: “GPIO”}, “status”: 1, “origin”: “rest”, “device”: “RelaySwitch”, “type”: [“DigitalActuator”]},
{“description”: “BURNER 1 / 6”, “name”: “J8uoHI3DwKFrHrMq”, “args”: {“channel”: 6, “invert”: false, “gpio”: “GPIO”}, “status”: 1, “origin”: “rest”, “device”: “RelaySwitch”, “type”: [“DigitalActuator”]},
{“description”: “Relay Switch 8 / 21”, “name”: “ownpnKnIEDoqzHHp”, “args”: {“channel”: 21, “invert”: false, “gpio”: “GPIO”}, “status”: 1, “origin”: “rest”, “device”: “RelaySwitch”, “type”: [“DigitalActuator”]},
{“description”: “Relay Switch 7 / 20”, “name”: “t6KCxynx5xnnsvEp”, “args”: {“channel”: 20, “invert”: true, “gpio”: “GPIO”}, “status”: 1, “origin”: “rest”, “device”: “RelaySwitch”, “type”: [“DigitalActuator”]},
{“description”: “Relay Switch 5 /12”, “name”: “1KGvFouswxtqFqLp”, “args”: {“channel”: 12, “invert”: false, “gpio”: “GPIO”}, “status”: 1, “origin”: “rest”, “device”: “RelaySwitch”, “type”: [“DigitalActuator”]},
{“description”: “BURNER_CIRC 2 / 26”, “name”: “7voqD9pprzrxusvn”, “args”: {“channel”: 26, “invert”: false, “gpio”: “GPIO”}, “status”: 1, “origin”: “rest”, “device”: “RelaySwitch”, “type”: [“DigitalActuator”]}]

Android app is ruled out of the equation and has nothing to do with the problem. I haven’t used it at all in the last run. (stupid idea stuck in my head but still ruled out) .
Ps: GPIO’S are operating with no problem

Thanks in advance, looking forward to further directions.

did you add any 1-Wire from the dashboard after they got detected ?


Same thing happened again five of six times in the last two days, proceeded by
sudo rm /etc/webiopi/devices.json
sudo nano /etc/webiopi/devices.json
pasted my cleaned up backup of devices.json, saved
sudo service webiopi restart

In the midst of all the trouble I made new a new ds18b20 array consisting of 5 brand new sensors and replaced the old set to ensure it is not related to the cabling.

I ran Ethernet cabling directly from the main router replacing the repeater providing Ethernet for the Pi2.

Made a new account and used a Raspberry pi 3 to reproduce the problem. Suddenly at 4:30 in the morning repeated sms warnings made clear that I wouldn’t be saved by any of the changes as the system has failed again.

To summarize, in random intervals(5 hours to 5 days) all of the sensors appear -214 degrees for a few minutes and once in a while new entries are being created for non existent sensors.
I desperately need a way to disable automatic 1-WIRE discovery, please advice, this is my last hope.


Nope nothing manually added, though considering my problematic situation, I would definitely prefer to have manual control of one wire registration.

We’re looking into this. Will respond again with update.


I suspect some temporarily hardware issue or with the 1-Wire kernel module, leading to bad detection : it detect a sensor with a wrong address that will don’t work, and give a -214 degree widget.

can you send me your /var/log/webiopi.log file ?

Hi there,
/var/log/webiopi.log is zero bytes, should I still send it?

Please be reminded that if you provide me with a way to disable 1 wire auto discovery the majority of my issues will be under control so I can proceed to further project development. Thanks in advance, Cheers!