Aye no problem Bob, just mentioned it out of interest no real issue for me 
Do feel free to mention. A lot of these minor issues are things we can and will fix.
1 Like
@pennengr I tried your eeprom, but it ran completely stable here. So I still don’t have a good idea why it crashes.
@Trig To investigate whether the bad connection to the DS2413 could cause system hangups, I created a tunabe shitty cable™.
With a variable resistor in the onewire line, I was able to trigger disconnectes around 90Ohm. With the resistor in the GND line around 5 ohm.
But the disconnects could not trigger a reboot.
Which leads me to another idea:
Maybe the power supply is playing a part. A too low voltage could cause the DS2413 to be underpowered, but could also cause problems elsewhere.
In the expanded version of the SparkPins widget (if you have a Spark 3), what is the voltage reported for 5V?
Another difference in our networks could the presence of other mDNS devices generating queries and responses. I spend the last couple of days completely rewriting the mDNS library. Maybe it will make a difference.
To validate my new implementation, I used Wireshark. It is a packet sniffer for your local netowrk. To investigate whether weird mDNS things happen on your network, you could use Wireshark with the filter ‘mdns’, that will show you all mdns traffic on the network.
Wireshark is a complex program that requires some knowledge about how networks work. So if you don’t have a background in IT, I don’t recommend trying it. But I’m mentioning it just in case.
Elco, the only thing that I can think of that was unusual was having done the update without the USB cable connected to the Spark the first time (if there was a warning message in the web GUI I missed it). I did just spend about 30 minutes cleaning in my brewery this afternoon and did not have any reboots - perhaps it has calmed down.
Is there an easy way to confirm that communication between the Spark and PI is over USB? I’ve had it plugged in since reflashing (via ssh).
Thanks.
We have just added an icon for that in the upcoming release!
The logs will also tell you whether it discovered a spark on USB or WiFi.
docker-compose logs --follow spark-one
You can force the use of USB, if you want, by adding the flag --discovery=usb to the service in docker-compose.yml.
Here’s my latest set of time stamps. Looks like it is running on USB if I read correctly:
park-one_1 | 2020/04/27 03:10:56 ERROR brewblox_service.repeater error during runtime: CommandTimeout(ListObjectsCommand)
spark-one_1 | 2020/04/27 03:11:16 INFO …_devcon_spark.communication Closed <SparkConduit for /dev/ttyACM0>
spark-one_1 | 2020/04/27 03:11:16 INFO brewblox_service.repeater resumed OK
spark-one_1 | 2020/04/27 03:11:18 INFO …_devcon_spark.communication Retrying connection…
spark-one_1 | 2020/04/27 03:11:18 INFO …lox_devcon_spark.connection Starting device discovery, type=all
spark-one_1 | 2020/04/27 03:11:18 INFO …lox_devcon_spark.connection Automatically detected [’/dev/ttyACM0’, ‘P1 - P1 Serial’, ‘USB VID:PID=2B04:C008 SER=4e002c001751353431383737 LOCATION=1-1.5:1.0’]
spark-one_1 | 2020/04/27 03:11:18 INFO …lox_devcon_spark.connection discovered usb /dev/ttyACM0
spark-one_1 | 2020/04/27 03:11:18 INFO …_devcon_spark.communication Connected <SparkConduit for /dev/ttyACM0>
spark-one_1 | 2020/04/27 03:11:29 ERROR brewblox_devcon_spark.seeder Failed to ping controller - CommandTimeout(NoopCommand)
spark-one_1 | 2020/04/27 03:11:48 INFO …_devcon_spark.communication Closed <SparkConduit for /dev/ttyACM0>
spark-one_1 | 2020/04/27 03:11:48 ERROR brewblox_devcon_spark.seeder Seeding timeout. Exiting now…
spark-one_1 | ======== Running on http://0.0.0.0:5000 ========
spark-one_1 | (Press CTRL+C to quit)
spark-one_1 | 2020/04/27 03:12:02 INFO brewblox_service.service Creating [spark-one] application
spark-one_1 | 2020/04/27 03:12:02 INFO main INI: firmware_version=‘666633f0’, firmware_date=‘2020-04-20 22:37:45 +0200’, proto_version=‘8cd025a’, proto_date=‘2020-04-03 14:51:16 +0200’, system_version=‘1.5.0’
spark-one_1 | 2020/04/27 03:12:02 INFO main CONFIG: host=‘0.0.0.0’, port=‘5000’, output=‘None’, name=‘spark-one’, debug=‘False’, eventbus_host=‘eventbus’, eventbus_port=‘5672’, simulation=‘False’, device_host=‘None’, device_port=‘8332’, device_serial=‘None’, device_id=‘None’, discovery=‘all’, history_exchange=‘brewcast.history’, state_exchange=‘brewcast.state’, command_timeout=‘10’, broadcast_interval=‘5’, broadcast_timeout=‘60’, broadcast_valid=‘60’, read_timeout=‘30’, mdns_host=‘172.17.0.1’, mdns_port=‘5000’, volatile=‘False’, skip_version_check=‘False’
spark-one_1 | 2020/04/27 03:12:02 INFO brewblox_service.service Service info: 0.5.2-386-g47f54dd @ Tue Apr 21 09:17:49 UTC 2020
spark-one_1 | 2020/04/27 03:12:02 INFO …lox_devcon_spark.connection Starting device discovery, type=all
spark-one_1 | 2020/04/27 03:12:02 INFO …lox_devcon_spark.connection Automatically detected [’/dev/ttyACM0’, ‘P1 - P1 Serial’, ‘USB VID:PID=2B04:C008 SER=4e002c001751353431383737 LOCATION=1-1.5:1.0’]
spark-one_1 | 2020/04/27 03:12:02 INFO …lox_devcon_spark.connection discovered usb /dev/ttyACM0
spark-one_1 | 2020/04/27 03:12:02 INFO …_devcon_spark.communication Connected <SparkConduit for /dev/ttyACM0>
spark-one_1 | 2020/04/27 03:12:13 ERROR brewblox_devcon_spark.seeder Failed to ping controller - CommandTimeout(NoopCommand)
spark-one_1 | 2020/04/27 03:12:32 INFO …_devcon_spark.communication Closed <SparkConduit for /dev/ttyACM0>
spark-one_1 | 2020/04/27 03:12:32 ERROR brewblox_service.repeater <SparkConduit for /dev/ttyACM0> error during runtime: SerialException(read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?))
spark-one_1 | 2020/04/27 03:12:32 ERROR brewblox_devcon_spark.seeder Seeding timeout. Exiting now…
spark-one_1 | ======== Running on http://0.0.0.0:5000 ========
spark-one_1 | (Press CTRL+C to quit)
spark-one_1 | 2020/04/27 03:12:42 INFO brewblox_service.service Creating [spark-one] application
spark-one_1 | 2020/04/27 03:12:42 INFO main INI: firmware_version=‘666633f0’, firmware_date=‘2020-04-20 22:37:45 +0200’, proto_version=‘8cd025a’, proto_date=‘2020-04-03 14:51:16 +0200’, system_version=‘1.5.0’
spark-one_1 | 2020/04/27 03:12:42 INFO main CONFIG: host=‘0.0.0.0’, port=‘5000’, output=‘None’, name=‘spark-one’, debug=‘False’, eventbus_host=‘eventbus’, eventbus_port=‘5672’, simulation=‘False’, device_host=‘None’, device_port=‘8332’, device_serial=‘None’, device_id=‘None’, discovery=‘all’, history_exchange=‘brewcast.history’, state_exchange=‘brewcast.state’, command_timeout=‘10’, broadcast_interval=‘5’, broadcast_timeout=‘60’, broadcast_valid=‘60’, read_timeout=‘30’, mdns_host=‘172.17.0.1’, mdns_port=‘5000’, volatile=‘False’, skip_version_check=‘False’
spark-one_1 | 2020/04/27 03:12:43 INFO brewblox_service.service Service info: 0.5.2-386-g47f54dd @ Tue Apr 21 09:17:49 UTC 2020
spark-one_1 | 2020/04/27 03:12:43 INFO …lox_devcon_spark.connection Starting device discovery, type=all
spark-one_1 | 2020/04/27 03:12:43 INFO …lox_devcon_spark.connection Automatically detected [’/dev/ttyACM0’, ‘P1 - P1 Serial’, ‘USB VID:PID=2B04:C008 SER=4e002c001751353431383737 LOCATION=1-1.5:1.0’]
spark-one_1 | 2020/04/27 03:12:43 INFO …lox_devcon_spark.connection discovered usb /dev/ttyACM0
spark-one_1 | 2020/04/27 03:12:43 INFO …_devcon_spark.communication Connected <SparkConduit for /dev/ttyACM0>
spark-one_1 | 2020/04/27 03:12:43 INFO …blox_devcon_spark.commander HandshakeMessage(name=‘BREWBLOX’, firmware_version=‘666633f0’, proto_version=‘8cd025a’, firmware_date=‘2020-04-20’, proto_date=‘2020-04-03’, system_version=‘1.5.0’, platform=‘p1’, reset_reason_hex=‘8C’, reset_data_hex=‘01’, device_id=‘4E002C001751353431383737’, reset_reason=‘USER’, reset_data=‘WATCHDOG’)
spark-one_1 | 2020/04/27 03:12:43 INFO brewblox_service.couchdb <CouchDBClient for http://datastore:5984> Existing document found (4e002c001751353431383737-config-db)
spark-one_1 | 2020/04/27 03:12:43 INFO brewblox_service.couchdb <CouchDBClient for http://datastore:5984> Existing document found (4e002c001751353431383737-blocks-db)
spark-one_1 | 2020/04/27 03:12:43 INFO …blox_devcon_spark.datastore <CouchDBConfig for spark-service/4e002c001751353431383737-config-db> Read 1 setting(s). Rev = 3-8185070790ead8912e21843ea24398e6
spark-one_1 | 2020/04/27 03:12:43 INFO …blox_devcon_spark.datastore <CouchDBBlockStore for spark-service/4e002c001751353431383737-blocks-db> Read 19 blocks. Rev = 450-4c7e90fc95585f4a060b93043320b4e6
spark-one_1 | 2020/04/27 03:12:43 INFO brewblox_devcon_spark.seeder Service synchronized!
spark-one_1 | 2020/04/27 03:12:48 INFO …blox_devcon_spark.datastore <CouchDBBlockStore for spark-service/4e002c001751353431383737-blocks-db> Saved 19 block(s). Rev = 451-da2e37fc20888190e0ae8f3d310aee37
Under docker-compose.yml I would change
spark-one:
command: --name=spark-one --mdns-port=${BREWBLOX_PORT_MDNS}
to
spark-one:
command: --name=spark-one --mdns-port=${BREWBLOX_PORT_MDNS} --discovery=usb
?
Thanks.
Yes, I see /dev/ttyACM0, so it is running on USB.
You have the correct change.
Hi Elco,
Thanks for the response. I have the Spark 2 which is powered by usb from a Raspberry Pi3.
I have downloaded Wireshark just to “have a look” Still working through the wiki but It is a bit out of my league.
At the moment I have all three fridges running and they appear to be doing their thing. Lucky the malfunction was on the cooling side so after re-warming, the fermentation recommenced.
I still see on the diagnostic dump a similar list of disconnects.
https://termbin.com/1wu2k
Any quick tips with the Wireshark to get what you need?
Just run the program with admin privileges, select your main network interface and type ‘mdns’ in the filter field.
It looks like you were first connected over WiFi, then switched to USB.
I would try to see which part of the RJ12 cabling is bad. How long is your cable? Do you have multiple long cables plugged into the spark?
I have a one cat5e cable from the pi to an expansion board in my first fridge which is approx 3m long, The other two are daisy chained into their expansion boards with RJ12, one is approx a 1m the other 3m.
I have run the program for a minute and have saved a .pcapng file but the extension is not recognised for upload.
You could zip it?
Something to try for the cables is to use one long chain. A split at the spark into two cables of a certain length going in different directions can create a dipole antenna. Maybe it even helps if you bind the cables together for the first 50-100cm.
I’m not sure of the exact cause, but I have seen a dipole antenna like configuration create problems before.
Sorry I was not clear enough, I only have one cable from the pi, the cat5e, the other two are chained from that fridge.
1 Like
What is the order and lengths in between? Where is this board that keeps disconnecting? Is it at the end?
Pi to Fridge 1 expansion 3m (cat5), to Fridge 3 expansion 3m (RJ12), to Fridge 2 expansion 1m (RJ12).
Just looked at the log again, address 3a06483900000021 belongs to Fridge 2 which is at the end of the chain. It was however Fridge 3 that had the cooling malfunction, the others were disabled at the time.
I don’t see strange traffic in your network log. Not much MDNS traffic either.
But it seems that the Spark was connected over USB at the time.
A network log during a crash would perhaps have some value, but it’s just a wild guess that might be related to network.
Your cables are a bit long. I think you might be near the limits of a reliable OneWire network.
A downside of the DS2413 perhaps, compared to direct pins, is that it has memory. It will remember the last written value as long as it has power. So if the Spark loses the connection while the pin is high, it stays high.
The DS2413 gets power from the OneWire bus, so losing communication but not power can only happen in the twilight zone. Enough connection for power, not enough for reliable communication.
Also check that you don’t have any cables running next to the OneWire cable that could have high current or spikes that cause interference. Your fridge power cables for example.
BTW, in your logs I see both DS2413s connecting and disconnecting.
Again thanks for your time, it seems I might have to relocate the Spark relative to the fridges and shorten the cables.
The Spark is connected to the Raspberry Pi with usb but the network connection is via wifi.
Is there any benefit to using cat5 over RJ12 cable?
RJ12 cable is used for phone lines and is very thin. I have not been able to find a thicker variant.
That is why the RJ12 cables in our store are made from CAT5, which has 8 strands instead of 6. We just leave 2 unconnected.
I assume you mean your Pi is wireless. The connection between Spark and Pi can be USB or wireless.
Yes the Pi is wireless.
I have used a 3m and 1m RJ12 telephone extension cables. The other is a length of cat5 that I have left two out. Maybe I should upgrade.