question

Hello Bob.

A few questions first.

Which version are you using?
How did you install the service? everything manual?

Your change:
fd = open('/sys/devices/w1_bus_master1/28-01203936a635/w1_slave','r') -> cannot work.

Undo this change and post the logs here.

to get the logs using this command inside ssh session:
tail -n 100 -f /data/log/VenusOS-TemperatureService/current | tai64nlocal

Hi @Rikkert-RS

Many thanks for your reply.

I'm using VenusOS-TemperatureService v0.52 with venus v2.66. (Python2).

All installed manually.

due to my data partition being full, dbus-i2c.py is in /opt /victronenergy/dbus-i2c not /data/VenusOS-TemperatureService, so I have edited my /service/run file to reflect this. I don't run updates to venus so being in this directory shouldn't matter. But it does mean my Log file is not where yours is, I can't find it hahaha. maybe it can't be created due to the data partition being full.

I made the fd = open('/sys/devices/w1_bus_master1/28-01203936a635/w1_slave','r') change as the temperature reading appears in /w1_slave and I do not have a file called /sys/devices/w1_bus_master1/28-01203936a635//temperature.

with my /w1_slave change in place, the system gets very confused and eventually crashes.

with it changed back, everything works apart from actually reading the temperature.

I'm thinking that my overlay is the problem as it is not creating the /temperature file but it's the overlay from your github filesets directory so should work with your dbus-i2c.py.

I'm confused now.

Yes, I think it's because of the overlay.

The "temperature" file from the 1Wire slave device is missing, otherwise it would work.

The log file would be good because otherwise troubleshooting would be very difficult.
The normal path is /data/log/ for all services. But I'm not sure where they are in version 2.66.
I don't have a system with this version to check, maybe under this path /var/log.

I've already considered installing a workaround if the temperature file doesn't exist and then getting the data from the w1_slave file.

It could also be due to Python2. I tested the driver with Venus OS version 2.90 (Python 3).

Be careful, if you run out of disk space it's not so good. This should always be avoided!

Why don't you want to update Venus OS?
Which Raspberry Pi do you actually use?

Hello @Bigbadbob76

To test, please replace dbus-i2c.py with this one:

dbus-i2c.zip

Hi @Rikkert-RS

Thank you for taking the time to look into this for me. I was struggling to parse /w1_slave.

I have replaced dbus-i2c.py with your test one.

now, at boot, it creates and removes the 1wire and cpu-temp services several times in the device list before locking up the gui.

running dbus-spy after the crash shows neither of them are running.

running dbus-i2c.py manually from PuTTY returns this-

root@raspberrypi2:/opt/victronenergy/dbus-i2c# ./dbus-i2c.py
INFO:root:./dbus-i2c.py is starting up - python 2
INFO:root:Loglevel set to INFO
Traceback (most recent call last):
File "./dbus-i2c.py", line 402, in <module>
dbusservice['cpu-temp'] = new_service(base, 'temperature', 'RPi_cpu', 'Raspberry Pi OS', SCount+1, 100, SCount+1)
File "./dbus-i2c.py", line 328, in new_service
self = VeDbusService("{}.{}.{}_id{:02d}".format(base, type, physical, id), dbusconnection())
File "/opt/victronenergy/dbus-systemcalc-py/ext/velib_python/vedbus.py", line 75, in __init__
self._dbusname = dbus.service.BusName(servicename, self._dbusconn, do_not_queue=True)
File "/usr/lib/python2.7/site-packages/dbus/service.py", line 142, in __new__
raise NameExistsException(name)
dbus.exceptions.NameExistsException: Bus name already exists: com.victronenergy.temperature.RPi_cpu_id01
Exception AttributeError: "'VeDbusService' object has no attribute '_dbusname'" in <bound method VeDbusService.__del__ of <vedbus.VeDbusService object at 0x7616a030>> ignored
root@raspberrypi2:/opt/victronenergy/dbus-i2c#

which doesn't look like it shows the problem.

@Bigbadbob76

ok it seems the Service is still running.

Have you checked whether the logs are under the path /var/log/ ?

Another try i changed something back

dbus-i2c.zip

hmmmm.....

with your previous test file,

stopping the service then running ./dbus-i2c.py manually returns-

File "./dbus-i2c.py", line 197, in update_w1

AttributeError: 'str' object has no attribute 'isnumeric'

I'll try your latest test file and report back.

same thing happens with latest test file.

I have confirmed w1_slave does still contain a numerical temperature value.

uncle google suggests this error is because i'm using python 2 and the string is not in unicode, under python 3 it is in unicode by default.

under /var/log there is nothing related to dbus-i2c.

Bingo!!!! uncle google was right.

I added m = unicode(m,'utf-8') after line 195 and all is good.

Thanks for your help. :-)

P.S. you asked...

Why don't you want to update Venus OS?

because I have made so many changes to v2.66 over the years that I would have to re-do from scratch in later versions using python 3. my generator control code in particular would be problematic, my gui changes not so much. but 2.66 works for me so I'll stick with it. although with a later version I could use Ruvi sensors and not need the 1-wire stuff. haha.

Which Raspberry Pi do you actually use? Pi2B. yep, I've been at this for years and still get lost jumping between python and qml.

@Rikkert-RS It’s chilly in the garage today. Snow outside.

@Rikkert-RS

I am now using two DS18B20 sensors in parallel. one on my battery and one outside the garage.

Could you please clarify for me if the same sensors will always be allocated the same W1-temp id on the dbus or if this is just the luck of the draw at boot/re-boot?

I have seen them swap over on VRM at re-boot but it might be my qml code that's at fault.

Cheers.

Bob.

Hello,

It can currently happen that the VRM ID changes when you restart and one sensor is recognized faster than the other.

But this does not apply to the names, type and dbus of the sensors. The names, type and dbus path are saved in the settings to match the sensor ID. In the next version I would also like to save the old VRM ID to settings so that it remains stable.

I'm looking deeper into this as when I connect the second sensor the readings drop out for several hours each day and then come back of their own accord.

I need to rule out hardware issues first but my deeper digging suggests that it's not the overlay that caused the issue of different paths but the kernel that the overlay calls.

As I am running an earlier version of venus (v2.66) the kernel included with that, which creates the directories for each sensor, is different from yours.

/sys/devices/w1_bus_master1/'+ id +'/temperature in your case

and..

/sys/devices/w1_bus_master1/'+ id +'/w1_slave in my case

Chances are the kernel was changed when venus changed from python 2 to python 3.

Even if I could find the kernel I doubt it would be human readable.

anyway, your revised dbus-i2c.py solved that problem.

Re: the sensors dropping out... I have expanded my data partition using a linux machine and now see some logging. :-)

one sensor reports CRC errors occasionally but they don't tie in with the drop-outs. I suspect a hardware issue...

So as a follow up...

When I only have one sensor connected, all is good. either sensor works for days. but with two connected, one or both drop out after several hours and then come back eventually after several more hours. they sometimes swap id.s too (w1_id02 swaps with w1_id03) depending on which one comes back first.

I have tried lower values of pullup resistor, 2.7k, 1.3k, 1k, no change.

I have added a 47nF capacitor across the 3.3v lines at the junction of the sensors. no change.

I have scoped the data line at the junction and the pulse edges look clean but have 300mv of ripple on the tops.

reading this - https://github.com/Rikkert-RS/VenusOS-TemperatureService/issues/11 makes me think its a hardware issue.

my setup is approx 10cm of open wires from the pi to the junction of the two sensors, one 5m, one 1m. so I'm connected in star topology but with short legs on the star so the impedance mismatch and timing differences should be small.

It looks like I have cloned sensors though as my serial numbers don't end in 0000xx so they might well not behave well together.

Update- I got some genuine sensors and they solved my problem. :-)

I also added an 8.3uF capacitor between 3.3v and gnd which got rid of the supply line ripple.