Hi,
meanwhile I found a "solution" based on this post.
I did an
apt-cache policy unipi-kernel-modules
which revealed the available version names.
Followed by
apt install unipi-kernel-modules=1.106.1.20220308~buster-1
it installed the previous version and all is smooth again.
Still, this is a workaround but not a solution.
/KNEBB
Thanks for your hints about downgrading. Worked for me, too.
For reference the commands here:
apt install unipi-kernel-modules=1.106.1.20220308~buster-1
I got the version by apt-cache policy unipi-kernel-modules.
/KNEBB
@CKB
Not sure it this might help you. But I have configured my OS to run "read-only". It helps for longer lasting SD cards and it will usually not corrupt upon power outage.
If you are interested, you might search for "Raspbian Read only".
See below my filesystems (just the main parts):
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=99612k,mode=755)
/dev/mmcblk0p2 on / type ext4 (ro,noatime)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /var/cache type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /var/tmp type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /var/log type tmpfs (rw,nosuid,nodev,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
And this is /etc/fstab:
PARTUUID=7965901e-01 /boot vfat ro,defaults 0 2
PARTUUID=7965901e-02 / ext4 ro,defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
tmpfs /tmp tmpfs nodev,nosuid 0 0
tmpfs /var/log tmpfs nodev,nosuid 0 0
tmpfs /var/tmp tmpfs nodev,nosuid 0 0
tmpfs /var/cache tmpfs nodev,nosuid 0 0
Greetings
/KNEBB
@Martin-Kudláček said in Upgrading to Bullseye?:
Hello everybody,
the upgrade to bullseye is planned for March.Best regards,
Martin
March has been gone now since two months.
So I am getting the feeling there is no effort put into getting it lifted to current stable?
Would be a pitty....
/KNEBB
@rob
I just upgraded to unipi-kernel-modules 1.112.1.20220308~buster-1 and it looks like they fixed the error.
Thanks for your hints about downgrading. Worked for me, too.
For reference the commands here:
apt install unipi-kernel-modules=1.106.1.20220308~buster-1
I got the version by apt-cache policy unipi-kernel-modules.
/KNEBB
Hi,
meanwhile I found a "solution" based on this post.
I did an
apt-cache policy unipi-kernel-modules
which revealed the available version names.
Followed by
apt install unipi-kernel-modules=1.106.1.20220308~buster-1
it installed the previous version and all is smooth again.
Still, this is a workaround but not a solution.
/KNEBB
Hi,
I noticed recently these messages in my syslog:
Apr 9 08:53:33 zentrale kernel: [ 200.867042] UNIPISPI: part1 b3:07:00:00
Apr 9 08:53:33 zentrale kernel: [ 200.972499] UNIPISPI: SPI CRC2 Not Correct: 2108 COMPUTED: 23f8
Apr 9 08:53:33 zentrale kernel: [ 200.972524] UNIPISPI: len=36, part1=fa:00:55:0e part2=00:82:00:a0:09:c5:80:00:00:00:00:00:00:00:00:00
Apr 9 08:53:33 zentrale kernel: [ 200.977253] UNIPISPI: SPI CRC2 Not Correct: 3200 COMPUTED: 10e5
Apr 9 08:53:33 zentrale kernel: [ 200.977276] UNIPISPI: len=42, part1=fa:00:55:0e part2=01:01:04:c0:00:00:00:0c:00:00:00:11:e5:00:40:00
Apr 9 08:53:33 zentrale kernel: [ 200.979490] UNIPISPI: SPI CRC1 Not Correct (Received: 0000 Calculated: 9b77)
I understand there is some CRC32 mismatch possibly related to some SPI device.
But what does it mean in detail and how can I prevent this message- or is something seriously broken?
I haven't noticed anything not working- but I am not using SPI devices (afaik).
Thanks in advance!
/KNEBB
Hi,
sorry again for annoying. I am still conmsidering upgrading. Unfortunately my quastion about how I can see if it it ready for Bullseye has not been answered.
From my point of view with the links I originally provbided it looks like it has not been upgraded up to now. Am I right here?
Thanks& Greetings
/KNEBB
Hi,
I use the IAQ sensor through MQTT. Working fine, really.
Just one point:
Could you improve the firmware so it will mark it mqtt messages as "retain"?
Reason:
When connecting to the mqtt topic the client currently does not get any information. When the retain flag is set the client will get the last information at least. Otherwise it has to wait for the next update.
With "retain" you get immediately a status.
Thanks!
/KNEBB
Hi all,
my Neuron M103 is running
root@neuron:~# cat /etc/issue
Raspbian GNU/Linux 10 \n \l
root@neuron:~# uname -a
Linux neuron 5.10.60-v7+ #1449 SMP Wed Aug 25 15:00:01 BST 2021 armv7l GNU/Linux
As this is oldstable I am thinking of upgrading to stable/ Bullseye (based on Debian11).
I am unsure about the Unipi repository. I found the KB article but this did not help.
Currently my /etc/apt/sources.list.d/unipi.list says:
root@neuron:/etc/apt/sources.list.d# cat unipi.list
deb https://repo.unipi.technology/debian buster main
Going to the repo main page it does not display any version information.
So my question here is:
Is it possible to upgrade to Bullseye? Or is the UniPi repository not yet at Bullseye?
How can I retrieve this information?
Thanks!
/KNEBB
Tahnks a lot!
Ok, mbpollnow delivers useful output which I do have to convert manually.
And yes, changing from 0to 1 for setting slave does not produce any timeout errors or similar.
Just, it still does not show the current values. I am always getting "0.000000" back (while mbpoll and the webpage show different values). No matter what address I use in the read call:
errlvl=modbus_read_registers(modbusglob, 6, 2, (&wert.word[0]));
Any further idea?
/KNEBB