Using FarmbotOS beta updates

Test-driving v8.0.0-rc25

[Configurator] Two fixme-s on the /network page; the MAC addresses for wired and wireless are not available.

[Don’t-know] Use the WebApp, Device page, Power and Reset to SHUTDOWN the bot actually causes a Reboot instead. The FarmBotOS.Platform.Target.SystemTasks.shutdown does the correct thing (power-off).

[FarmBotOS] The configured (advanced) optional NTP 1 and NTP 2 servers are ignored.

2 Likes

Thanks for the reports. We just fixed the reboot and ntp issues. Working on the mac address one next

2 Likes

Road-testing v8.0.0-rc27 using API at https://my.farm.bot

[Maybe-Infrastructure] Farmbot app: farmbot exited 0: :shutdown after many NervesHub.Supervisor crashes.

This then causes endlessly repeating FarmBotOS re-boot. (period about 3 minutes)

Also (probably not related to v8.0.0)
The RPi serial console reports (every 2nd boot or so) early after Erlang VM starts :

(edit in actual msg :))
kmsg_tailer: (null): sendfile: Broken pipe

That’s very strange. Ill check this out. Thereay be a race condition that needs catching or maybe there was a momentary breakage in infrastructure like you said

Hi,

I was testing Release v8.0.0-rc29 today and had some trouble with taking pictures:

Is this supposed to work at the moment? I saw that @connor recently made changes to the farmware interface so I am not sure if this still is work in progress.

Also after upgrading from 7.0.1, the first-party farmware was completely missing. I re-flashed the SD card and manually installed the camera farmware to have it at least show the error message.

Cheers,
Daniel

Please see this post for what is and is not expected to work as of this time

Now testing v8.0.0-rc29 with the https://my.farm.bot API.

Still have that repeating (3 minute) Farmbot app: crash followed shortly by OS Restart.

Will see what I can make of the Erlang stack traces. (Not sure it’s Infrastructure, but I am way over in Ausstrayliaah . . and previous poster seemed to have their bot up long enough to play with :slight_smile:)

<edit>
Think I have a clue on this one . . I always just grab the .IMG from the GitHub Pre-Release artefacts, check its sha256sum then burn it to a known good SDHC then go and Configurate it, etc…

Others probably use the NervesHub to do an OTA update !! I wonder if that’s it ??

I just booted a v8.0.0-rc29 that I built locally and it’s staying up.

@connor, in your copious spare time, could you grab a .IMG from Release and see whether it behaves badly for you too ? :slight_smile: Thanks !

hmm that’s a good question if an image file works. I had my doubts that beta images would work. I’ll try it out

I’ve opened an issue #850 and hopefully fixed with #851. Still waiting on continuous integration to build it please test it out when it’s up.

Update:
I just tested and it seemed to work. Let me know if it works for you

Thanks . . but still not working on my RPi :slight_smile: in fact v8.0.0-rc35 assets won’t even boot !?

Tried the .IMG and then tried fwup-ing the .FW file . . in each case, the RPi just does 4 slow Red blinks and 4 fast Red blinks, repeating, until I remove power. Nothing on the serial console.

You must be using a RPI 3b+. I just fixed this in the latest RC

1 Like

Yes, RPi 3 B+ is the same machine I’ve used since before 7.0.1 :wink:

v8.0.0-rc36 won’t boot either.

< Oh, wait ! >

I just see v8.0.0-rc37 . . I’ll give that a spin. :slight_smile:

Aaaaahhhhhhh . . the sweet sounds of machinery humming :sunny: Thanks ! ( -rc37 .IMG )

Those User-specified NTP server names are still being ignored, however :confused:

AND this seems new on the Serial Console for this Pre-Release

Huh i thought i fixed this. I’ll reopen the ticket.

That is normal, unfortunately. It is espeak opening the sound device. ALSA is just really noisy for some reason. I could probably add a config file of some sort with all the defaults to prevent it, but it’s not that big of a deal. To get serial logs, you should be able to do a RingLogger.attach()

1 Like

On -rc38 now but NTP server names config still not activated.
Maybe this one belongs with the :nerves_time app. ?

May have another issue coming . . I just need to dig deeper / debug it some more.

I’m in AU (Australia) and the WiFi Configurator AP is painfully slow and unresponsive, even on my trusty Ubuntu laptop.
I usually end up using the serial console and IEx to setup the basic network and credentials.

I noted that the AP is using US reg.dom. WiFi channels . . I need to check whether this is a problem.

You are setting these values from configurator right? they aren’t checked after configuration time so if your device was already configured they probably wouldn’t be used.

Yes, these were set from the /config_wired Configurator page, Advanced fields.
The persisted values I showed were sampled after at least one OS full reboot.

How many kmsg_tailer processes is enough ? (21 ?) Raspberry Pi 3 B+ on 8.0.0-rc41

( Only went looking because poor old RingLogger got duplicate after duplicate of the dmesg message set :slight_smile: )

Oh, and also, why is udhcpc running on my wired interface ??
< D’Oh, of course, it needs to renew leases and all that jazz . . sorry >

Lol. Getting connected to NervesHub often requires restarting :nerves_runtime which apparently doesn’t cleanup after itself. Really I only use that for development so maybe I’ll just disable it in production releases.

As for the udhcpc on eth0, I assume you are using static? That could cause problems if there is a DHCP server running. I’ll make a ticket for that one

1 Like

Hey, thanks @connor, pls. don’t bother with that udhcpc on eth0 mention !
I corrected my misteak with an edit which you may have missed.

DHCP wired works well, and, I haven’t bothered trying "static" "wired" _ because I didn’t know that VintageNet supports it yet (?)