Chances of getting this in Docker

[tanzimabir]

Hey guys, love the project and the lore behind it.

I was wondering if this could be a docker container?

I was also wondering:

1. If I could have it on my home server and have all the displays in the house pointed to it but show different things?

2. If there could be a user management or a client management page after the /admin page pull request that I came across just now. So that each client can have a separate db of messages to be shown.

3. AND/OR a local keyed API that home assistant can use to send custom messages to a specific or all clients as status updates/notifications and/or warnings!

I know this probably sounds easier in my head than it actually is (to me who has a very minimal experience with coding), and I am not here to demand features. Just sharing the thoughts I had after coming across this project on threads!

[Kevkotsu]

Hey guys, love the project and the lore behind it.

I was wondering if this could be a docker container?

I was also wondering:

1. If I could have it on my home server and have all the displays in the house pointed to it but show different things?
2. If there could be a user management or a client management page after the /admin page pull request that I came across just now. So that each client can have a separate db of messages to be shown.
3. AND/OR a local keyed API that home assistant can use to send custom messages to a specific or all clients as status updates/notifications and/or warnings!

I know this probably sounds easier in my head than it actually is (to me who has a very minimal experience with coding), and I am not here to demand features. Just sharing the thoughts I had after coming across this project on threads!

I think I'll take a look at the project and try to build what you mean. :)

[vultuk]

@tanzimabir Currently with the admin area I built (#2) it's probably not too difficult to flesh out to have different boards based on giving each a specific url. e.g. /screen-1, /screen-2 etc.

The PR also includes a RESTful system for sending messages to boards, as such we could adapt this to allow specifying the screen name so you can send to specific boards.

If my PR gets accepted I'm happy to adapt it to add these features as I think they would be useful.

[Kevkotsu]

@tanzimabir Currently with the admin area I built (#2) it's probably not too difficult to flesh out to have different boards based on giving each a specific url. e.g. /screen-1, /screen-2 etc.

The PR also includes a RESTful system for sending messages to boards, as such we could adapt this to allow specifying the screen name so you can send to specific boards.

If my PR gets accepted I'm happy to adapt it to add these features as I think they would be useful.

But is your RESTful system also compatible with Home Assistant ?

[vultuk]

@Kevkotsu I haven't actively tested, but based on the documentation here it should work with similar config to this in it's current incarnation.

rest_command:
  flipoff_set_message:
    url: "http://YOUR_FLIPOFF_HOST:8080/api/message"
    method: post
    content_type: "application/json"
    payload: '{"message":"Server driven updates are live"}'

  flipoff_clear_message:
    url: "http://YOUR_FLIPOFF_HOST:8080/api/message"
    method: delete

Then call it with

action: rest_command.flipoff_set_message
data:
  message: "Dinner is ready"

[vultuk]

I’ve implemented the multi-display part of this and it’s included in my PR (#2)

FlipOff now supports multiple boards, each with its own set of screens. Boards can be served from their own route using /board-slug, and one board can be marked as the default so it appears at /.

The API now supports targeting a specific board with boardSlug, and manual screens can also be targeted directly with boardSlug + screenSlug.

For Home Assistant, the call can now look like this for a specific board:

rest_command:
  flipoff_send_message:
    url: "http://YOUR_FLIPOFF_HOST:8080/api/message"
    method: POST
    content_type: "application/json"
    payload: >
      {
        "boardSlug": "{{ board_slug }}",
        "message": "{{ message }}"
      }

Example service call:

action: rest_command.flipoff_send_message
data:
  board_slug: bedroom
  message: Washer cycle complete

If boardSlug is omitted, FlipOff sends the message to the current default board.

I’m not doing anything on the Docker side because that’s already being handled in a separate PR (#7).