Straffern
I am currently tinkering with a poc, which is a rewrite of an existing product originally implemented in Python.
I recently saw a presentation on :gen_statem, and wanted to play around with it. I quickly realised that it might fit nicely my case.
The problem/case:
The existing product functions both as a SaaS product and a “firmware” for an IoT product. Given that I hope to utilise Nerves, for the IoT product, I suddenly see a case for adding additional states, that only is a concern for the Nerves variant of the product.
What I’m asking
Is it possible to develop a standalone software, that can run in a container, but also be imported and extended in the Nerves software?
Such that I can extend the “Sensor” gen_state_machine, adding additional states, and override a selection of callbacks already implemented in “Sensor” module?
Do I need a macro for this?
Is this bad practice?
Thanks! 
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
You don’t. If you think about it you’re doing the same with gen_statem already. It provides the underlying logic on how to run a state machine, while the module you implement provides the logic of which states act how.
You could provide your own behaviour and extension points within to further allow another behaviour implementing module to extend what you built on top of gen_statem.
Straffern
Its possible that I’ve misunderstood behaviours.
So I basically just add a bunch of typespecs for callbacks & types, similar to the implementation of gen_state_machine, and then make some state_function overridable?
LostKobrakai
That would be one way to do that, yes.
You can see similar “stacked implementations” with e.g. LiveView.
use Phoenix.LiveViewwith all it’s callbacks: Phoenix.LiveView — Phoenix LiveView v0.19.5Phoenix.LiveView.Channel, which is aGenServer: phoenix_live_view/lib/phoenix_live_view/channel.ex at v0.19.5 · phoenixframework/phoenix_live_view · GitHubGenServer.Similarly for plain channels
use Phoenix.Channelmodules are also started asGenServerprocesses.Straffern
I don’t think I understand.
Looking at the second link with Phoenix.Liveview.Channel, I see no use of Phoenix.Liveview
LostKobrakai
It’s the other way round. The channel isn’t a LV. But the channel is what “runs” a LV.
E.g. here you can see it forwarding non-internally-handled
handle_infomessages to the liveview:https://github.com/phoenixframework/phoenix_live_view/blob/v0.19.5/lib/phoenix_live_view/channel.ex#L421