First some more flaming, then a real solution...
I mostly agree with the flames already thrown at you.
I disagree with key-value normalization. Queries end up being horrible; performance even worse.
One 'simple' way to avoid the immediate problem (limitation of number of columns) is to 'vertically partition' the data. Have, say, 5 tables with 400 columns each. They would all have the same primary key, except one might have it being AUTO_INCREMENT.
Perhaps better would be to decide on the dozen fields that are most important, put them into the 'main' table. Then group the sensors in some logical way and put them into several parallel tables. With the proper grouping, you might not have to JOIN all the tables all the time.
Are you indexing any of the values? Do you need to search on them? Probably you search on datetime?
If you need to index lots of columns -- punt.
If you need to index a few -- put them into the 'main table.
Here's the real solution (if it applies)...
If you don't need the vast array of sensors indexed, then don't make columns! Yes, you heard me. Instead, collect them into JSON, compress the JSON, store it into a BLOB field. You will save a ton of space; you will have only one table, with not column limit problems; etc. Your application will uncompress, and then use the JSON as a structure. Guess what? You can have structure -- you can group the sensors into arrays, multilevel stuff, etc., just like your app would like. Another 'feature' -- it is open-ended. If you add more sensors, you don't need to ALTER the table. JSON if flexible that way.
(Compression is optional; if your dataset is huge, it will help with disk space, hence overall performance.)