@sdetweil Simple enough! Thanks! I added this to custom.css:

div#module_5_calendar {
  overflow: hidden;
  max-height: 210px;
}

Some of the events that I’m pulling from external calendars have long names, and they wrap onto two (or more!) lines. While the calendar module exposes an option to control the maximum number of entries which appear, if a couple of these long entries come along, the calendar module grows excessively to contain them.

Is there a way, whether by module config or CSS, to limit the maximum number of lines in the calendar, or the maximum height? (I’ve tried height limitations in CSS, but the module appears to happily expand past the bounding box if the content is large.)

@sdetweil

Okay, I think I have a clean repro of the issue in https://github.com/MikeBishop/MMM-asyncdeath – the synchronous start function produces this in the logs and loads normally:

[21.01.2023 14:55.02.692] [LOG]   Synchronous start-up -- all is well
[21.01.2023 14:55.02.693] [LOG]   Sockets connected & modules started ...
[21.01.2023 14:55.03.235] [LOG]   Launching application.

The async start function produces this in the logs and fails:

[21.01.2023 14:52.54.143] [LOG]   About to break by using await
[21.01.2023 14:52.54.884] [LOG]   Launching application.
[21.01.2023 14:52.56.512] [LOG]   Sockets connected & modules started ...

Note the reversed order of “Launching application” and “modules started”. Seems feasible this could also happen with a synchronous module startup that takes a long time, but I haven’t tested that.

@sdetweil

That’s actually how I installed this instance to begin with. However, I’ve narrowed my instance of the problem down.

The node_helper for the module I wrote, MMM-Powerwall, has an async start() function. In previous MM versions, the startup code didn’t wait on async start functions to finish, and my init finished not long after MM started. This version includes the fix to wait for async modules to finish starting. I’ve confirmed that my start() function is running to the end, and MM does write

[21.01.2023 14:30.25.915] [LOG]   Sockets connected & modules started ...

…to the log, but apparently something about waiting on the module breaks the electron browser. If I hack the module to look synchronous, like so:

start: /*async*/ function () {
		this.asyncStart()
	},	

asyncStart: async function () {

…everything starts right up. Something about the timing or threading of waiting for modules to complete is making the electron launch fail, I think.

My next step will be to make a module that does nothing but has an async node_helper and see if I can repro the issue with that.

@chris_d, any chance that you’re also using a module with an async start function?

@sdetweil

Bullseye, looks like. Whatever’s in the newest RPi OS release, anyway.

For the moment, I’ve swapped back to the other SD card that’s working. System’s been a little flaky the last few days, figured I’d try a fresh install on a new card in case that’s starting to go; hit this issue on the new one. When I have a few minutes to pull the Pi from the mirror and bring it back to my desk, I’ll give npm start dev a try on the newer one.

@sdetweil

I’m having what appears to be the same problem – HDMI is black (but apparently happy from the log output), while browser access is fine. I can’t get the dev tools to come up in Electron; perhaps unsurprisingly, the browser dev tools don’t show any errors that weren’t there on my old instance.

I just upgraded to the latest version, and most of my modules are broken, specifically any module that uses a node_helper. It looks like messages from the modules are reaching the helper, but no responses are coming back to the client.

I tried re-cloning the MM repo and copying over the config/modules with a fresh npm install, but it produces the same result. I feel like I’m missing something basic here, but I’m not sure what else to check.

@mumblebaj, chart.js needs to come from npm. If you do npm install chart.js, what does it say?

Also, recent versions have taken a couple of dependencies that require newer Node versions – what version are you running? (node --version)

I see the exceptions thrown on retrieving Storm Watch status; I’ve just pushed a commit to ensure that skips if it gets null back for now. However, besides log pollution, that shouldn’t actually be breaking anything – Node will log that it failed and move on to the next message.

That renders as the text, for some reason. However, the cake shows up properly after apt install fonts-noto-color-emoji and a reboot.

Running on a Raspberry Pi 4, and one of my calendar feeds has emoji in the event names. When accessing the MM with a browser, they display fine; on the screen connected to the Pi, however, they’re just little squares.

I know this is more likely an electron, Node, or XWindows issue than MM itself, but has anyone found a solution for getting emoji to render properly?

@NicB72, I’d love to work with you on both of these.

The intent is that the car tile will periodically rotate through the cars on the account; if cars are charging and your TWC is capable of reporting VINs (not all are), then it will show the cars currently charging; otherwise, it rotates through all of them on your Tesla account.

Now, the limiting factor: I only have one Tesla vehicle, so I’ve never been able to test that code path with several. 😁 Sounds like it’s not working. Send me a private message, and we can hopefully figure out why. If you’re moderately handy with webdev, you might want to put breakpoints in the functions focusOnVehicles() and advanceToNextVehicle() to figure out why they’re always choosing the same vehicle.

The way I’d expect it to work with MMM-Carousel is that you’ll have multiple instances of MMM-Powerwall, each displaying a single graph. MMM-Carousel would then be responsible for rotating through the several instances, while the messages from the node_helper make them all stay in sync. (Though now that you mention it, there might be a bit of conflict between the CarCharging graph rotating between cars and MMM-Carousel rotating through all of them. Hm.) There’s a fork of MMM-Carousel that has more robust support for multiple instances of the same module in slides mode, though the original might work fine in global or positional mode.

When you say they’re tiny… How tiny? The individual graphs are currently fixed-size at 430x250; if that’s too large for your screen, you might have some success with a CSS scale() transform.

Hi, Dano - did you do an npm install to pick up the dependencies? If not, you won’t have chart.js installed, which means no graphs.

@lavolp3 said in MMM-Powerwall:

I want to have a powerwall, a solar panel and a tesla just to try out this module!

My total bill for the set was over $100k, so I wouldn’t recommend it as purely dev kit. 😉 That said, I love them all.

Description:

Displays a collection of live graphs with data from your Tesla Powerwall (and TWCManager, if you have one) on your Magic Mirror.

Screenshots:

This module implements several different graphs. Currently, these are:

• CarCharging
  
• PowerwallSelfPowered
  
• SolarProduction
  
• HouseConsumption
  
• EnergyBar
  
• PowerLine
  

By default, all are displayed. However, as needed by your layout, you can
instantiate multiple instances of this module, each displaying different graphs
or even targeting different Powerwall systems. Multiple instances referencing the same target will still update simultaneously and will not increase the volume of
requests made to either local or cloud endpoints.

Download:

https://github.com/MikeBishop/MMM-Powerwall

I see that the installer installs Node 10.x, with 12.x being the most recent LTS version. Has anyone tested MM2 with Node 12 or 14? Is there a specific reason to remain on the maintenance branch?