Style nit: you can inline this.
Also Println:

• already adds a /n at the end of the line.
• Joins all given arguments with a whitespace character.

• You can use the multi-line var syntax here, which allows to group symbols together, preferably semantically.
• Also, I don't see why we need to repeat morserino here. It doesn't bring much information, does it ?
• What does debugLevel means ? Shouldn't it be logLevel ?
• Those variable names are pretty self descripting. The comments only repeat what is already stated by the variable. I suggest you remove them?

Design nit: What is this structure role? What is its responsibility in regard of your application logic?
Usually we try to have one structure, one behavior. Here it seems that this structure is a technical factorization, not a semantic one which isn't the best.

Alsoooo, is repeating Morserino really necesasry here? We're already under the morserino package 😄

If you don't care about the actual data carried inside the channel, use chan struct{} instead (literally chan of empty struct} which doesn't allocate any space for the data.

You can use it like this

c := make(chan struct{})
c <- struct{}{}

Nit: Prefer using Initialization function instead of Init method: doing the later exposes you to the risk of manipullating sturctures in an ill state (and it makes your structure more complicated to manipulate from the caller).

var c MorserinoChannels
// c is in an ill state, if I call anything on it it will panic
c.Init()
// now we're good

VS

cs := NewMorserinoChannels()
// And we're good :tada:, no risk of panics here.

Careful with that commented line 😄

I'm not in fond of this change: You're removing an error return and instead push down a set of channels that makes the code more complicated to understand.

How about keeping your error return and run the OpenAndListen in an anonymous function like this:

var errCh = make(chan error)

// ...

go func() {
         if err := OpenAndListen(foo, bar); err != nil {
              errCh <- err
         }
}() 

Also, most of your operations here are initialization phase error (aka misconfigured application for example) , not properly runtime. Those operations should be handled synchronously in your main goroutine I believe.

Maybe leverage a struct here, WDYT ?

type Listenser struct {

}

// Initialization function for the initialization phase 
func NewListener(cfg Config) (*Listener, error) {
     // Initialize things that could fail synchronously
     smth, err := initializeSomething(cfg);
     if err != nil {
         return nil, err
     }
     
     return &Listener{smth: smth}, nil 
}

Another "smell" that makes me think this is your function name OpenAndListen: you're doing two things in the same function that could be separated.

Does it make sense ?

Instead of exposing your synchronization primitive, how about hiding this being an interface, something like.

type MessageWriter interface {
       WriteMessage(msg string) error
}

And hide the "technicalities` of how you actually send a message behind this ?
It will give you much better readability and testabillity 😸

From the caller It will be much more easier:

_ = w.WriteMessage("\nEOF")

Having to introduce this is kind of a smell: You can have multiples goroutines writing concurently to your buffer, which in some cases can be OK but I suspect it is not in yours 😺.