using versus import in Julia: which one do I need to add methods to another module's function?

Both load the module; they differ in which names become visible and whether you may add methods through the unqualified name. using Foo makes Foo itself and everything Foo exports available, so you can call bar(x) directly. import Foo makes only the name Foo available, and you write Foo.bar(x). using Foo: bar and import Foo: bar each bring in just that one name.

The key rule: a name that arrived through using can be called but not extended by its bare name. A name brought in with import Foo: bar can.

So there are two correct ways to add a method. Either qualify the definition, Base.show(io::IO, r::Reading) = print(io, r.value, " V"), or import the name first, import Base: show, +, and then define show(io::IO, r::Reading) = .... Many people prefer the qualified form, because the definition itself shows which function is being extended.

For operators the qualified spelling is Base.:+(a::Reading, b::Reading) = Reading(a.value + b.value); the colon is needed for operator names.

What happened in your first attempt: inside your module, show had not been used yet, so show(io::IO, r::Reading) = ... created a brand-new function YourModule.show that merely has the same name. Printing calls Base.show, which knows nothing about it. If the module had already called show before that line, the name was resolved to the one from Base, and the definition is then rejected with the "must be explicitly imported to be extended" error. Same mistake, two different symptoms.

parentmodule(show) evaluated inside your module tells you which function the name refers to.

Two related habits. For a module you wrote yourself in a file, include("Sensors.jl") runs the file and defines the module, and then using .Sensors with the leading dot refers to that local module rather than to an installed package. Include the file once, in one place: including it from two different files creates two separate modules whose types have the same names but are not the same types, which leads to puzzling method errors.

And in library code, prefer using Foo: bar, baz with an explicit list over a bare using Foo. It documents where each name comes from and avoids clashes when two packages export the same name.